Lerdge S controller connection issue


#1

Hi all.

I'm trying to connect Octoprint to a UM2+ clone running a Lerdge S 32 bit board.

For months it has kind of worked albeit with the occasional delay ( press home wait 20 seconds or so for the printer to react) but since the recent upgrade, i cant get any response out of the printer.

The Lerdge 32bit board is unfortunately closed source. However, all configuration that would typically be in config.h, takes place thru the provided touch screen and works great.
http://www.lerdge.com/
The ledge board needs a plug-in adapter to provide serial communications ( which also has a socket that accepts a ESP8826 wifi unit)

So while testing i have removed the wifi unit ( for fear of it interfering with serial comms). If i connect a laptop to the printer and run Pronterface it works fine and prints and accepts gcode commands (115200 baud). So I'm a bit lost as to why it doesn't play nice with a Raspi3 running Octoprint ( and nothing else)
I know the Raspi / Octoprint are fine as if i connect them to one of my other printers the work without issue.

I have found the "serial logging' option in Octoprint but need some help on how to get the log file "off" the raspi.
While i consider myself relatively conversant with the working of 3D printers, my Linux skills are sadly lacking.

All help advice appreciated
Cheers


#2

You don't really need any Linux skills to retrieve the logs, just browser power!

Start with the wrench at the top, select Logging on the left side, use the little numbers below the file list to scroll, click the download icon at the end of the serial.log line and it will appear in your Downloads folder on your desktop.


#3

Adjust the serial settings in OctoPrint manually to 115200. That 20-second delay is OctoPrint trying the highest speed, failing, choosing a different speed, failing... until it finally finds the right one.


#4

Ok thanks for the reply . I have set both the baud and serial port manually and it connects immediately now.
The main issue is the delay when sending commands .
Comm's on my network appear to be fine. Files upload to Octoprint just as fast as they do on my other printers.


#5

Thanks . I cant believe i've failed to see that before ! ill take a look at that and see if i can get any info from the log file. In the mean time, when i connect to the printer it reports back with some info in the terminal window but then freezes


#6

here's the serial log file
It seems that the communication times out but then it executes the command anyway.
Im a bit confused as to what Octopi does differently than Proterface ( which still works fine) PhilM serial log Octopi-Lerdge 21062018.log (3.2 KB)

PS ive just made an SD boot with a previous version and it has the same issue so its not as i originally thought a "new version " bug


#7

I'm not at my printer now but somewhere in the Settings for Serial is an adjustment for the idle timeout. Try 120 seconds for that one.


#8

Your firmware has a consistent bug on its temperature responses that's causing the acknowledging ok to be sent neither as a prefix (which would work fine) nor on its own line (which would work fine) but instead just shoves at the end (probably due to a missing line break in the firmware code, which will not work fine):

echo: T:28.7 /0.0 B:28.6 /0.0ok

All the responses to M105 look like this, so it's unlikely this is a transmission problem and rather a firmware bug. That echo: prefix is also wrong but wouldn't hurt. Things should like this:

T:28.7 /0.0 B:28.6 /0.0
ok

or this:

ok T:28.7 /0.0 B:28.6 /0.0

From the looks of your log, this isn't the only case where your firmware doesn't comply to basic communication protocol:

  • It doesn't know M110 (reset line numbers): echo:Unknown command: "M110 N0"
  • Its M115 response is split across multiple lines:
    2018-06-21 03:00:47,830 - Recv: FIRMWARE_NAME: Lerdge 3D
    2018-06-21 03:00:48,031 - Recv: FIRMWARE_VERSION: V2.0.8
    2018-06-21 03:00:48,034 - Recv: FIRMWARE_URL: www.lerdge.com
    2018-06-21 03:00:48,036 - Recv: MACHINE_TYPE: FDM:Normal_XYZ
    2018-06-21 03:00:48,038 - Recv: HOTEND_NUMBER: 1
    2018-06-21 03:00:48,040 - Recv: EXTRUDER_NUMBER: 2
    2018-06-21 03:00:48,042 - Recv: HOTEND 1 MAX T: 300.000
    

And from past experience with firmware that gets basic stuff like this wrong already, you are probably in for a couple more surprises down the road.

Since these issues appear to be consistent, what could be done here is quickly cobble together a plugin that rearranges the broken temperature response so that at least communication can proceed properly, and then see where that gets you.

Try throwing this file into ~/.octoprint/plugins and restarting the server. To do this on OctoPi, SSH into your instance, then:

cd ~/.octoprint/plugins
wget -Ofix_lerdge3d_temp.py https://git.io/fCxLE
sudo service octoprint restart

PS: your printer firmware's vendor really needs to fix their stuff - this is sadly yet again a case of someone developing firmware who apparently has no idea how the serial messages are supposed to look and introducing fatal issues in the process. There may not be a well defined protocol (which is a huge part of why this keeps happening), but there is an established de facto protocol and this firmware is going against that in multiple ways.


#9

It requires a bit more consistency from the printer because it does a whole bunch more than Pronterface.


#10

Thanks for the response Much appreciatted . I have a line of communication to Lerdge thru one of their dealers so i will report back the issues highlighted by you and hope they take notice. To date they have been quite pro active in fixing bugs and releasing new firmware revisions so i'm hoping they will take note.
I also have retained copies of their previous firmware so i plan to go back a couple of revisions and see whether the issues existed then or has recently arisen.
I will keep you posted as and when they respond.

Thanks for the plugin . Ill give that a try later tonight and see what that brings
Cheers


#11

no luck with the temp fix im afraid . It installed fine and i can see it identified as installed in the plugin manager but still the same issue with the "ok" at the end rather than a new line.


#12

Hi Just reverted back to an older version of their firmware and all is well. See pic

Clearly they have messed up the serial comm's on this latest 2.0.8 release.
Thankyou for the support on an issue that now clearly has nothing to do with Octoprint.


#13

Please run over to their github, create an issue and let them know about the missing hard return before the "ok" in the recent release. (Think of all the other users you can help out.)


#14

They don't have a github repo Their firmware is closed source.
I will report to them as i have now tried 3 previous versions of their firmware which work fine. its the latest version which has the comm errors

I was introduced to this board thru a friend and at the time was building a printer so decided to try it out.
It actually works very well and the configuration thru the touch screen is pretty straight forward. Ideal for people who don't want to or cant deal with Arduino IDE and firmware sketches.
If your interested heres a link to their set up page(s) layout http://www.lerdge.com/case_view.aspx?TypeId=30&Id=406&Fid=t2:30:2


#15

Dear Phil,
I'm running two S-Boards and now also an K-Board on the printer I have.
Was trying to upgrade to 3.01 including bootloader 1.04 on the S-Board but the touch screen comes instantly out of range. Why this upgrade? Because it was told to me by Peter from Lerdge that this was solving wifi issues.
Are you or is somebody familiar with this problem?
Any suggestions other than going back to release 3.0?

Back to your posting: did you ever manage to upgrade to 3.0 and using octopi / octoprint to communicate?
I'm trying but it's super slow and I get timeouts
Any suggestions?
Thanks


#16

Dear Phil,
I'm struggling to get connected to my S-Board (Firmware 2.08)
You are mentioning a manual setting for the serial connection, can you explain how, I'm lost with this.
Thanks


#17

Sorry EVD i gave up on getting the Lerdge board to work reliably. too much hassle