Command passthrough doesn't work - ie Octoprint -> Printer

[CRCinAU]

I can connect fine - and if I set options like M900 K0.68 in OctoPrint, I can see that step-daemon does interpret things properly..... However nothing seems to make it through to the printer.

I use /dev/ttyACM0 at 250000 - but the Octoprint M105 / M115 commands never return with the expected values (or any values) so nothing proceeds.

Sending a G28 / G29 / G1 Z0 etc result in no movement and seem to just disappear...

$ java -jar server/target/scala*/*.jar -Xmx64M -XX:+UseG1GC -XX:ParallelGCThreads=4 -XX:ConcGCThreads=2 -XX:MaxGCPauseMillis=5
Preloaded 1788 classes, and 3 failed
[INFO] [07/09/2020 07:34:56.566] [stepd-akka.actor.default-dispatcher-7] [akka://stepd/user/device/line-serial] starting...
[INFO] [07/09/2020 07:34:56.663] [stepd-akka.actor.default-dispatcher-8] [akka://stepd/user/pipeline] Pipeline started, draining for 2 seconds
[INFO] [07/09/2020 07:34:56.675] [stepd-akka.actor.default-dispatcher-8] [akka://stepd/user/device] Resetting command state
[INFO] [07/09/2020 07:34:56.676] [stepd-akka.actor.default-dispatcher-8] [akka://stepd/user/bed-level] Loading mesh level data
[INFO] [07/09/2020 07:34:56.681] [stepd-akka.actor.default-dispatcher-8] [akka://stepd/user/bed-level] No leveling data found.
rm: cannot remove '/tmp/pty-stepd-client': No such file or directory
[INFO] [07/09/2020 07:34:56.729] [stepd-akka.actor.default-dispatcher-5] [akka://stepd/user/device/line-serial/serial] ArraySeq(/dev/ttyACM0)
rm: cannot remove '/tmp/pty-stepd': No such file or directory
[INFO] [07/09/2020 07:34:56.739] [stepd-akka.actor.default-dispatcher-6] [akka://stepd/user/proxy] 2020/07/09 07:34:56 socat[1485] N starting data transfer loop with FDs [5,5] and [7,7]
[INFO] [07/09/2020 07:34:56.740] [stepd-akka.actor.default-dispatcher-6] [akka://stepd/user/proxy] Linking /dev/pts/1 to /tmp/pty-stepd-client
[INFO] [akkaDeadLetter][07/09/2020 07:34:56.740] [stepd-akka.actor.default-dispatcher-7] [akka://stepd/user/proxy] Message [com.colingodsey.stepd.PrintPipeline$DeviceRestart$] from Actor[akka://stepd/user/pipeline#-890000906] to Actor[akka://stepd/user/proxy#185387138] was unhandled. [1] dead letters encountered. This logging can be turned off or adjusted with configuration settings 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'.
[INFO] [akkaDeadLetter][07/09/2020 07:34:56.741] [stepd-akka.actor.default-dispatcher-7] [akka://stepd/user/proxy] Message [com.colingodsey.stepd.PrintPipeline$ResumeInput$] from Actor[akka://stepd/user/pipeline#-890000906] to Actor[akka://stepd/user/proxy#185387138] was unhandled. [2] dead letters encountered. This logging can be turned off or adjusted with configuration settings 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'.
[INFO] [07/09/2020 07:34:56.757] [stepd-akka.actor.default-dispatcher-6] [akka://stepd/user/proxy] Linking /dev/pts/2 to /tmp/pty-stepd
[INFO] [07/09/2020 07:34:56.762] [stepd-akka.actor.default-dispatcher-6] [akka://stepd/user/proxy] linking done
[INFO] [07/09/2020 07:34:56.774] [stepd-akka.actor.default-dispatcher-8] [akka://stepd/user/proxy/proxy-serial] ArraySeq(/dev/ttyACM0)

[INFO] [07/09/2020 07:35:40.952] [stepd-akka.actor.default-dispatcher-5] [akka://stepd/user/pipeline/delta] syncing pipeline position

Is something broken between the pipes?

I can see the app and socat running in a ps list:

0 S pi        1590   778 65  80   0 - 288916 futex_ 88300  2 07:38 pts/0    00:00:06 java -jar server/target/scala-2.13/print-server-jvm-assembly-0.1.0-SNAPSHOT.jar -Xmx64M -XX:+UseG1GC -XX:ParallelGCThreads=4 -XX:ConcGCThreads=2 -XX:MaxG
0 S pi        1630  1590  0  80   0 -  1447 poll_s  2520   1 07:39 pts/0    00:00:00 socat -d -d pty,raw,echo=0 pty,raw,echo=0

[colinrgodsey]

Did you build Marlin with the DIRECT_STEPPING feature enabled? There's a specific log-line that generally shows up when Marlin reports that its ready to start sending direct stepping pages.

[colinrgodsey]

also, additional note: im rewriting this currently. the new version will be more verbose about its state management, should make these things less mysterious

[CRCinAU]

I do have #define DIRECT_STEPPING enabled.

If I understand correctly, even if it was failing at the stepping part, I should still be able to pass though Mxxx commands? Such as temp reporting, M503 etc etc? Right now it's like a black hole.

If I close step-daemon, and connect to the printer with screen and start temp auto-reporting, then start step-daemon again, I note that I continue to see the auto-temp reports flow though ttyACM0 -> step-daemon -> OctoPrint.

I'm happy to wait until you publish the re-write etc if that's easier.... I'm kind of excited to try it out :)

[CRCinAU]

Just as a note, I'm building Direct Stepping firmware for testing here: https://marlin.crc.id.au/firmware/Ender%203%20-%20Direct%20Stepping/

I think you might be able to get more help if you commit your 'work-in-progress' to a development branch or similar that people can contribute to...

[colinrgodsey]

Yeah, good idea. I'm going start an issue for the rewrite so its clear what needs to be done if anyone wants to contribute. The current scala codebase with the octoprunt plugin is just... so bad.

As far as what the logs above, it looks like something triggered a device reset maybe and crashed the pipeline. The way the pipeline is done here currently is rather error-prone, and may blackhole error messages with no feedback. The proposed go pipeline should be much more rigid and will tie the process state to the device state (the process just restarts when the device does).

[colinrgodsey]

The go rewrite has much improved serial management now :+1: