Fully support Repetier firmware

[Mattasmack]

I'm having trouble getting CWH to control my SLA printer and I can't for the life of me figure out where it's going wrong. I'm using a Pi version 1 with a fresh install of Raspbian (installed via the latest version of NOOBS yesterday), and was able to install CWH without any obvious errors, connect to its web interface, and set up a printer. When I click on the green 'start' button for the printer on the printers page, the pi's screen goes black but nothing changes on the webpage (the 'stop' and 'controls' buttons remain unclickable, no error message appears). The printer's icon on that page always has a red crossed-circle through it in the printer list (meaning it's offline, I assume) and it never becomes controllable. But if I click on the 'start' button again, I get an error message titled 'Error On startPrinter' stating that the display is already assigned (to this very same printer).

I feel a little silly raising this as an issue here since I've probably just set something up incorrectly, but I can't figure out what that might be or how to proceed debugging it.

LogBundle.zip

[jmkao]

No worries, that's what we're here for.

To help give context to your LogBundle, what kind of printer do you have, what kind of firmware do you use (e.g. Marlin on a Mega+RAMPS, or something else), and what kind of projector do you have?

[Mattasmack]

That was fast!

The motor controller is an Arduino with RAMPS board running an older version of Repetier firmware (leftover from an old Reprap ...). It works fine when connected to my desktop and running Creation Workshop. I used the same port parameters (115200bps, 8N1) in CWH and checked that they and the port are correct by connecting to it with minicom.

At the moment I just have the Pi's HDMI connected to my monitor so that I can see when anything happens. I wanted to disturb the printer itself as little as possible while getting this software running, and I assume the exact display device attached doesn't matter as long as there is one at all. It's an Asus monitor, 1920x1080 resolution.

I don't have a serial line attached for projector control; I wasn't planning on using that feature, at least for now.

[kloknibor]

Serial seems fine, trouble starts with the display... It says it's already assigned... How and why I'm not sure... But you must have gotten that error to right?

[kloknibor]

Maybe try to flash this to your sd card, it has cwh preinstalled ;)! : http://s3-us-west-2.amazonaws.com/photonic3d/photonic-image.zip

[Mattasmack]

I do get an error message related to the display, but only on the second go-round. When I first boot the pi, the screen shows the usual Pi X desktop. The first time I hit the 'start' button on the web interface, the screen goes black and I see no change or message on the webpage at all. Clicking the start button again after that returns an error message about the screen.

I'll try that image next!

[kloknibor]

Also you may have to little patience :p in the first versions I clicked start to soon after clicking start the first time, this threw errors back than ;)! I would install the image, configure it and click start and show some patience :)

Verstuurd vanaf mijn iPhone

Op 15 mrt. 2016 om 19:29 heeft Mattasmack notifications@github.com het volgende geschreven:

I do get an error message related to the display, but only on the second go-round. When I first boot the pi, the screen shows the usual Pi X desktop. The first time I hit the 'start' button on the web interface, the screen goes black and I see no change or message on the webpage at all. Clicking the start button again after that returns an error message about the screen.

I'll try that image next!

— You are receiving this because you commented. Reply to this email directly or view it on GitHub

[jmkao]

It looks like some state handling issue in the way the display is mapped to the printer. I think I have experienced something like this before. If I start a printer and then stop it before it's done starting, then there may be some kind of resource leak, but I'm not 100% sure.

You probably do not need to reinstall anything to get by this. Try sshing into the RPi and go into /opt/cwh. Run ./stop.sh, and then ./start.sh. That will clear out all the state and you can try starting the printer again.

The key areas from the log seem to be an attempt to start the printer, which appears to be successful, and then somehow the system is getting repeated attempts to start the printer again.

2016-03-14 20:17:09,966 DEBUG o.a.r.p.PrinterManager [qtp18312385-14] Attempting to start printer:LittleRP
2016-03-14 20:17:13,021 INFO o.a.r.d.DisplayManager [qtp18312385-14] Display:X11GraphicsDevice[screen=0] assigned to Printer:LittleRP(printerFirmwareSerialPort:null, projectorSerialPort:null Display::0.0)
2016-03-14 20:17:13,036 DEBUG o.a.r.p.PrinterManager [qtp18312385-14] Assigned display:X11GraphicsDevice[screen=0] to:LittleRP(printerFirmwareSerialPort:null, projectorSerialPort:null Display::0.0)
2016-03-14 20:17:13,119 INFO o.a.r.s.SerialManager [qtp18312385-14] Attempting to assign firmware using serialPort:Autodetect 3d printer firmware with settings:{Port:Autodetect 3d printer firmware speed:115200 databits:8 parity:None stopbits:One handshake:None} to printer:LittleRP(printerFirmwareSerialPort:null, projectorSerialPort:null Display::0.0)
2016-03-14 20:17:13,142 INFO o.a.r.s.SerialManager [qtp18312385-14] Attempting to autodetect resources for:PrinterFirmware using serialPort:Autodetect 3d printer firmware with settings:{Port:Autodetect 3d printer firmware speed:115200 databits:8 parity:None stopbits:One handshake:None} to printer:LittleRP(printerFirmwareSerialPort:null, projectorSerialPort:null Display::0.0)
2016-03-14 20:17:13,246 DEBUG o.a.r.s.SerialManager [qtp18312385-14] Autodetection testing serial device:/dev/ttyACM0
2016-03-14 20:17:13,328 DEBUG o.a.r.s.SerialManager [qtp18312385-14] Attempting 3dprinter firmware detection on:{Port:/dev/ttyACM0 speed:115200 databits:8 parity:None stopbits:One handshake:None}
2016-03-14 20:18:06,640 INFO o.a.r.s.ProgressiveDownloadServlet [qtp18312385-18] HTTPGet:/video/camera.mp4
2016-03-14 20:18:06,657 WARN o.a.r.s.ProgressiveDownloadServlet [qtp18312385-18] File doesn't exist:/tmp/temp.mp4 for resource:http://piprinter:9091/video/camera.mp4
2016-03-14 20:18:36,995 DEBUG o.a.r.p.PrinterManager [qtp18312385-18] Attempting to start printer:LittleRP
2016-03-14 20:18:37,012 ERROR o.a.r.p.PrinterManager [qtp18312385-18] Error starting printer:LittleRP
org.area515.resinprinter.display.AlreadyAssignedException: Printer already assigned to::0.0
    at org.area515.resinprinter.display.DisplayManager.assignDisplay(DisplayManager.java:58) ~[cwh/:?]
    at org.area515.resinprinter.printer.PrinterManager.startPrinter(PrinterManager.java:120) [cwh/:?]
    at org.area515.resinprinter.services.PrinterService.startPrinter(PrinterService.java:193) [cwh/:?]
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_65]
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_65]
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_65]
    at java.lang.reflect.Method.invoke(Method.java:497) ~[?:1.8.0_65]
    at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.9.Final.jar:?]

[Mattasmack]

Some progress!

I have the photonic image on the pi, and I've gotten back to where I started with the same problem.

It finally occured to me to try varying the printer settings: If I set both the display and the motors serial port to simulated, the start and stop functions work just fine. If I set the display to the real display, that also works fine, and I can display the calibration screen. If I set the motors serial port to anything other than simulated (i.e., autodetect or the actual serial port), I get the same problem I started with.

Could the firmware on the Arduino be a problem? Is there a particular known-good firmware I should try switching to? (jmkao mentioned Marlin earlier I think)

kloknibor, how much patience are we talking about? I've tried clicking on start and walking away for ~15 minutes, and still nothing happens.

[WesGilster]

Can you try out the development version. I was having the same problem of Multiple starts from the GUI causing havic. This commit was designed to fix this: https://github.com/WesGilster/Creation-Workshop-Host/commit/ac84e08423ba2de3c1b30e7f8fc4309a5ce7ce78

[Mattasmack]

I used /opt/cwh/startdev.sh and now have version 0.275 running. Still getting similar behavior: With anything but the simulated serial port, when I click on 'start' I see the projector screen go blank, then nothing happens for several minutes. If I click 'start' again, I get a different message, telling me that the printer is being started and can't be started again. But it still seems to be stuck in this 'starting' state forever, until I kill it with /opt/cwh/stop.sh and start over. I'm going to try a different firmware next. If Repetier is constantly sending text through the serial port, could that somehow cause cwh to get hung up?

[Mattasmack]

Well I'll be darned, I replaced old Repetier firmware with current Marlin on the Arduino, and now it works! Or the printer starts and the manual controls work, anyway. I haven't tried printing anything yet; that's next after I do some calibrating.

[kloknibor]

15 minutes is enough patience :p good to hear it works with marlin now :)! And if you can send manual gcode, than printing won't be a problem ;)! One you confirmed it working could you confirm here to be sure? Thanks!

Op 15 mrt. 2016 om 23:37 heeft Mattasmack notifications@github.com het volgende geschreven:

Well I'll be darned, I replaced old Repetier firmware with current Marlin on the Arduino, and now it works! Or the printer starts and the manual controls work, anyway. I haven't tried printing anything yet; that's next after I do some calibrating.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub

[WesGilster]

That's great that you got this working. Although I'd really like to dig into this further. It looks like I'm not placing the display back into the pool of available displays once a failed start has occurred. I don't suppose you could attach the logs from my development version?

[Mattasmack]

kloknibor: Thanks! I will do so, though probably not until tomorrow. I'm about out of time to work on this tonight.

Wes: Here you go. Once I've made a few prints that I've been waiting for, if need be I'd be happy to put Repetier firmware back on my controller to try to replicate the problem, too.

LogBundle.zip

[WesGilster]

It looks like this is a bug, but maybe not where we all believed it was. It turns out that every time he tried a printer start, the display was legitimately already allocated. The problem looks like it might be in detecting the Repetier firmware. Let's walk through a few of his startups:

2016-03-14 20:17:09,966 DEBUG o.a.r.p.PrinterManager [qtp18312385-14] Attempting to start printer:LittleRP 2016-03-14 20:18:36,995 DEBUG o.a.r.p.PrinterManager [qtp18312385-18] Attempting to start printer:LittleRP

That is him trying to start the printer twice. We've all done it, happens to the best of us. If we are all doing it, then we may need to open an enhancement to make it more clear that the printer is trying to start...

2016-03-14 20:24:27,022 DEBUG o.a.r.p.PrinterManager [main] Attempting to start printer:LittleRP 2016-03-14 20:26:01,351 DEBUG o.a.r.p.PrinterManager [qtp18312385-83] Attempting to start printer:LittleRP

This is him attempting to start the printer after autostart has been enabled on the printer. If autostart isn't finished, then we can't expect our start to work...

2016-03-14 21:36:02,253 DEBUG o.a.r.p.PrinterManager [main] Attempting to start printer:LittleRP 2016-03-14 21:44:01,252 DEBUG o.a.r.p.PrinterManager [qtp18312385-13] Attempting to start printer:LittleRP

Same issue here:

2016-03-14 21:59:16,954 DEBUG o.a.r.p.PrinterManager [qtp1698919-18] Attempting to start printer:LittleRP 2016-03-14 22:02:29,137 DEBUG o.a.r.p.PrinterManager [qtp1698919-15] Attempting to start printer:LittleRP

Autostart was turned off on this run, but we are getting the same result as the beginning. This goes on throughout his logs... I'm also betting against these events being ghost starts, since theses are on different jetty requests with quite a bit of time between the start events. Generally ghost starts relating to double posts(and other web issues) are in very close proximity to each other.

The logs from his development version show a similar picture, but with a proper error message. What is consistent in the logs is that firmware opening is frozen...

2016-03-14 20:17:13,328 DEBUG o.a.r.s.SerialManager [qtp18312385-14] Attempting 3dprinter firmware detection on:{Port:/dev/ttyACM0 speed:115200 databits:8 parity:None stopbits:One handshake:None} 2016-03-14 20:24:32,554 DEBUG o.a.r.s.SerialManager [main] Attempting 3dprinter firmware detection on:{Port:/dev/ttyACM0 speed:115200 databits:8 parity:None stopbits:One handshake:None} 2016-03-14 20:17:13,328 DEBUG o.a.r.s.SerialManager [qtp18312385-14] Attempting 3dprinter firmware detection on:{Port:/dev/ttyACM0 speed:115200 databits:8 parity:None stopbits:One handshake:None} 2016-03-14 20:24:32,554 DEBUG o.a.r.s.SerialManager [main] Attempting 3dprinter firmware detection on:{Port:/dev/ttyACM0 speed:115200 databits:8 parity:None stopbits:One handshake:None}

...and then when autodetection was being used, it's still frozen.

2016-03-14 21:05:32,367 INFO o.a.r.p.Printer [main] Firmware serial port set to:/dev/ttyACM0 2016-03-14 21:36:10,083 INFO o.a.r.p.Printer [main] Firmware serial port set to:/dev/ttyACM0 2016-03-14 21:59:20,655 INFO o.a.r.p.Printer [qtp1698919-18] Firmware serial port set to:/dev/ttyACM0 2016-03-14 22:29:40,427 INFO o.a.r.p.Printer [qtp12042244-13] Firmware serial port set to:/dev/ttyACM0 2016-03-14 22:07:49,974 INFO o.a.r.p.Printer [qtp1953829-16] Firmware serial port set to:/dev/ttyACM0

So the big question is: where did it freeze in the code? I have some really good suspicions, but I don't know for certain because my stackdumps aren't getting logged. Very annoying, but I'll get this working before I ask you to reproduce under Repetier again.

[WesGilster]

I've fixed the stackdump issue in my dev branch(loosely related to a build issue). The point is, I should be able to capture the method that is freezing your start procedures for the Repetier firmware.

No rush, just take the diagnostic when you know a printer start is in progress on your old firmware.

Available in cwh-0.277.

[Mattasmack]

I've run some test prints with Marlin loaded on the Arduino, and it all seems to work fine. It's nice to be able to run the printer without having it tethered to my desktop!

Then I reloaded Repetier and confirmed that I get the same behavior as before. Here is a new set of log files with version 0.277 running and two attempted starts of the printer.

Wes, I agree with your comment that it would be nice to have some indication that the printer is starting. Even when the printer started successfully, I often saw a delay of a few seconds before the printer showed as started. It would be good to indicate more quickly that the click on the 'start' button really did register and something is happening.

LogBundle.zip

[WesGilster]

Great, I love hearing another success. The stacktrace was a bit surprising, and it looks like you knew the problem all along and I didn't catch it:

If Repetier is constantly sending text through the serial port, could that somehow cause cwh to get hung up?

Yes, this is problematic because most 3d printer firmware I've worked with sends a finite chitchat "welcome" message. This message is annoying because it doesn't follow any format, but at least I can take comfort in knowing that it will eventually end. This basically means I keep reading data until there is a break. The problem is that Repetier never stops talking and I never stop reading...

As a part of another bug, I'm going to address some other gcode parsing routines this weekend. I assume that it will have to stop talking once I send it my first gcode, if not, I'm not quite sure how I'll get it to shutup. I might have to checkout their code a bit to see what they are looking for.

[Mattasmack]

I don't know if it even needs fixing, really, as long as it's noted somewhere prominent that Repetier firmware is problematic. This application doesn't demand much of the motor controller compared to FDM printers, and I don't think there's anything special in Repetier vs. other firmwares that's applicable here. It's just the firmware that I happened to have installed to start with.

[WesGilster]

I'll be in the middle of that code anyway this weekend, so I'll see what I can do. Plus, I'd rather display in a prominent place that Repetier is supported than unsupported. :)

[3dModeller]

I also use the Repetier firmware in my homemade 3D printer and had the same problems. But now it seems to work.

[WesGilster]

@3dModeller I would be interested in seeing a logbundle that covers the startup period for your printer. I've designed the gcode parser to be pretty resilient against problems, but I am a little unsure as to how it could ever work with Repetier, if there isn't at least a 2 second break between any two consecutive bytes.

[3dModeller]

Unfortunately I get the e-mail settings not to work in CWH. I think this are the files "cwh.log" "log.out" and "log.err" you need. I'll send them manually to you.

[WesGilster]

You can just drag and drop them into the github comments box.