Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No multi serial in version 1.0.1 #799

Open
ThomasHamke opened this issue Jun 24, 2018 · 9 comments

Comments

@ThomasHamke
Copy link

commented Jun 24, 2018

I'm trying to install a Bluetooth JY-MCU / HC-06 module. This works like a charm with version 0.92.8 but not with 1.0.1 with identical Configuration.h. On V1.0.1, oscilloscope shows a straight line of 0 V on Tx pin of the board. On 0.92.8 it shows the "wait+CRLF" sequence once a second. I tried serial ports 1 and 3 without success. Serial0 is OK in both versions.

Hardware is a delta printer with Trigorilla board (mostly pin compatible fork from RAMPS 1.4, without pin D0 & D1). I considered the common tutorials and issues:

  • using a voltage devider 5V->3.3V
  • configured BT module with external programmer and AT commands
  • set parameter BLUETOOTH_SERIAL to 1 resp. 3:
    #define BLUETOOTH_SERIAL 1
    #define BLUETOOTH_BAUD 115200
  • defined / undifined EXTERNALSERIAL in configuration.h as well as HAL.h: has no influence in any version
    #define EXTERNALSERIAL
  • remapped the Z endstops (resp. Y endstop) pins:
    #define ORIG_X_STEP_PIN 54
    #define ORIG_X_DIR_PIN 55
    #define ORIG_X_ENABLE_PIN 38
    #define ORIG_X_MIN_PIN -1 // 3
    #define ORIG_X_MAX_PIN 3 // 2
    #define ORIG_Y_STEP_PIN 60
    #define ORIG_Y_DIR_PIN 61
    #define ORIG_Y_ENABLE_PIN 56
    #define ORIG_Y_MIN_PIN -1 // 14
    #define ORIG_Y_MAX_PIN 2 // 15
    #define ORIG_Z_STEP_PIN 46
    #define ORIG_Z_DIR_PIN 48
    #define ORIG_Z_ENABLE_PIN 62
    #define ORIG_Z_MIN_PIN 14 // 18
    #define ORIG_Z_MAX_PIN 15 // 19
  • Checked endstops working properly

While compiling there are warnigs in this sequence:

HAL.h:80:0: warning: "SERIAL_RX_BUFFER_SIZE" redefined
#define SERIAL_RX_BUFFER_SIZE 128

HardwareSerial.h:53:0: note: this is the location of the previous definition
#define SERIAL_RX_BUFFER_SIZE 64

HardwareSerial.h:147:25: warning: type of 'Serial1' does not match original declaration
extern HardwareSerial Serial1;

HardwareSerial1.cpp:61:16: note: previously declared here
HardwareSerial Serial1(&UBRR1H, &UBRR1L, &UCSR1A, &UCSR1B, &UCSR1C, &UDR1);

HardwareSerial.h:143:25: warning: type of 'Serial' does not match original declaration
extern HardwareSerial Serial;

HardwareSerial0.cpp:70:18: note: previously declared here
HardwareSerial Serial(&UBRR0H, &UBRR0L, &UCSR0A, &UCSR0B, &UCSR0C, &UDR0);

I modiefied only configuration.h and pins.h. Each other src file is original from release 1.0.1 plus I'm using the TMC2130 library for tree axis.

Many thanks in advance,
Thomas

@repetier

This comment has been minimized.

Copy link
Owner

commented Jun 25, 2018

Can you comment the
HAL.h:80:0:
#define SERIAL_RX_BUFFER_SIZE 128

into

// Can not change buffer size here, need add build flag -D SERIAL_RX_BUFFER_SIZE=128
//#define SERIAL_RX_BUFFER_SIZE 128

For me it compiles then without issues. It seems not possible to change RX buffer size, because arduino compiles it with 64bytes by default. So using multi buffer reduces in this case the buffer size to 64, which is important for host software. This at least makes it compile without warnings as all use same definition.

An other thing is that responses are normally only written to the serial that did the query and not to all outputs like it was before. Try
M155 S1
for testing. This is autoreport temperatures and should write temperatures every second to all outputs. Otherwise this would also explain why you see no output if you did not query that port.

@ThomasHamke

This comment has been minimized.

Copy link
Author

commented Jun 25, 2018

OK, thanks until then. Compiling was without warnings after following your advice. But the serial ports still did not work. M155 S1 had no effect. Even the 'wait+CRLF' sequence had not been sent. Zero communication...

After some fiddling I got Serial1 working by commenting out this statement:
//#define EXTERNALSERIAL
in Configuration.h and HAL.h

Then in gcode.cpp was &RFSERIAL2 unknown. I had to change
#if BLUETOOTH_SERIAL > 0
SerialGCodeSource serial1Source(&RFSERIAL2);
#endif
into
#if BLUETOOTH_SERIAL > 0
SerialGCodeSource serial1Source(&RFSERIAL);
#endif

Then I got the first signals to the oscilloscope but many communication errors on Repetier Host:

Error:expected line 2 got 3

I solved this in gcode.cpp by replacing this
#if BLUETOOTH_SERIAL > 0
fast8_t GCodeSource::numSources = 2; ///< Number of data sources available
fast8_t GCodeSource::numWriteSources = 2;
GCodeSource *GCodeSource::sources[MAX_DATA_SOURCES] = {&serial0Source,&serial1Source};
GCodeSource *GCodeSource::writeableSources[MAX_DATA_SOURCES] = {&serial0Source,&serial1Source};
#else
fast8_t GCodeSource::numSources = 1; ///< Number of data sources available
fast8_t GCodeSource::numWriteSources = 1;
GCodeSource *GCodeSource::sources[MAX_DATA_SOURCES] = {&serial0Source};
GCodeSource *GCodeSource::writeableSources[MAX_DATA_SOURCES] = {&serial0Source};
#endif
GCodeSource *GCodeSource::activeSource = &serial0Source;
by this
fast8_t GCodeSource::numSources = 1;
fast8_t GCodeSource::numWriteSources = 1;
GCodeSource *GCodeSource::sources[MAX_DATA_SOURCES] = {&serial1Source};
GCodeSource *GCodeSource::writeableSources[MAX_DATA_SOURCES] = {&serial1Source};
GCodeSource *GCodeSource::activeSource = &serial1Source;

A test print was successful.
This is just a bad workaround. But there is maybe an idea what the real cause could be.

@odaruc

This comment has been minimized.

Copy link

commented Feb 19, 2019

@daninfuchs

This comment has been minimized.

Copy link

commented Jun 30, 2019

@ThomasHamke - Thanks so much for the detailed information, however I seem to be unable to reproduce your 'fix' presently. (v1.0.3)

My goal is to have USB free for firmware uploads, and use hardware serial - ideally at faster than 115200 - direct to the RPi's GPIO (via level converter obviously) to control the printing process. I don't care if serial 1 is the ONLY port that works, I just need it to work.

Presently I've got it working using serial 0 and SHARED with the USB-to-serial onboard, which I hate. It makes me very uncomfortable.

I connected a second interface to Z-Min/Z-Max/Gnd and moved Z-Min to Y-Max, connected them to the level converter instead of D0/D1, and applied your code block change - I did not modify hal.h:80 as described above since it had already been, in my code tree.

I'm 100% unable to establish comms on Serial 1 (aka Bluetooth) at any speed. I can, however, connect it to Serial 0 (USB-shared) and everything seems to be working as before - this confirms that the level converter and my wiring are both OK, and yes I verified (and even swapped) TX/RX to be sure it wasn't that.

Is there something I've missed? Thanks for any attention I can get!

@repetier

This comment has been minimized.

Copy link
Owner

commented Jun 30, 2019

Just checked the pin description and for serial 1 it seems correct. Only serial 2 seems to be wrong regarding the pin numbers.

But did you also test the raspberry settings. Do you have /dev/ttyAMA0 and configured linux to not have a serial console for linux (console=null in /boot/cmdline.txt). Otherwise there will be only garbage.

If you have a logic analyser you could check in tx line if you get "wait" every second when not connected.

@daninfuchs

This comment has been minimized.

Copy link

commented Jun 30, 2019

I did mention that I'm using the same setup with the onboard Serial0 (which is shared with the serial-to-USB chip) so I know the level converter and RPi are working perfectly. It's printing behind me right now, as such. Has stable 5v and 3.3v references on the level converter, good grounding, immaculate wiring and connector work. I did switch to hardware serial for /dev/ttyAMA0 with the overlay change previously, and my waveform shaping on serial data is sharp and clean when using Serial0 - admittedly I didn't actually scope it on Serial1, but it was one of those "it works with the other connector, should work here" dealies in my mind at the time.

Actually since it's running right now, still with the modified code and Bluetooth enabled to Serial1, and the cable is still installed - what is expected behavior on Serial1 during a print? I assume from the code I saw that it's going to show duplicated firmware-side feedback as if it were speaking to the host? No host chatter (Serial0 RX) expected to show on Bluetooth's (Serial1 TX) port? I'll pull out my DSO and see if there's anything, or if it can be resolved to ASCII while I wait to hear your thoughts. (Thank you!)

@daninfuchs

This comment has been minimized.

Copy link

commented Jun 30, 2019

Okay so here's some fun.

Serial data shows up properly until it's hooked up. I'm using bidirectional level converters because that's what I had on hand, which - paired with the MKS Gen v1.4's inbuilt resistor madness on the endstop pins - results in, apparently, triggering the tristate on the bidirectional converter chip. That's my working theory at least, I'm gonna have to do some physical modifications to verify it, but according to the schematic the endstops (All three sets) are the middle leg in a resistor network between 5v and the MCU.

Very unusual, and explains why it works in some cases but not others - I'm likely using a more tempermental level converter. Sorry to take up your time! Sorry I didn't think to actually look at the signals before coming here, thanks for straightening me out. I'll let you know if this doesn't work out.

EDIT: Fixed. You're awesome, thank you. For future travellers being insane with MKS Gen v1.4;
To 'direct-wire' Z-Max/Z-Min for Serial1;

  • Remove R20, R27, R28, R30
  • Jumper R28, R32 (0 ohm or straight wire)

To 'direct-wire' Y-Max/Y-Min for Serial3;

  • Remove R18, R19, R35, R36
  • Jumper R35, R36 (0 ohm or straight wire)

Standard disclaimer, don't do this unless you're crazy and have a very specific need, DO NOT hook up an endstop to the connector pair EVER AGAIN (without reversing this!) and enjoy.

photo_2019-06-30_02-50-07

@repetier

This comment has been minimized.

Copy link
Owner

commented Jun 30, 2019

I'm not so into electronics so do not fully understand. Do you mean the end stops on MKS are hard wired as pull up with the resistors? Quite unexpected as the AVR can do that internally as well if wanted.

@daninfuchs

This comment has been minimized.

Copy link

commented Jul 1, 2019

More or less, yes they are. A weak one, weak enough that the MCU itself can overcome it to idle low with pullups disabled.

I'm as surprised as you are - why in the world would they do that? That's why I straight-up ASSUMED it had to be a firmware thing, haha. RAMPS v1.4 doesn't do that. I really don't get it - it's just as likely your average user is going to make a mistake wiring that as any other pin, it can be configured pull-up or not just as any other pin, or ignored in whatever N/C state it's left. I'm not aware of any special on-powerup tricks any common AVRs do on those pins. The mind boggles!

Clip from the schematic, proof for proof's sake;

endstops

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.