Connecting multiple duets to one SBC
-
@chrishamm Thanks for the quick reply! Would this concept (in theory) be expandable to as many instances as needed until the pi runs out of power at some point?
Will try it and report back (but might take a bit)
-
@benecito Each DSF instance requires some CPU + memory to keep the OM updated and sharing the same SPI port may introduce extra lags, so I'd only connect independent SPI ports if possible. Please let me know how it goes!
-
@chrishamm Will report back after some experimenting, or when running into some issues
-
@chrishamm
I just figured out the wiring but can't start a second DCS instance.I duplicated
/opt/dsf/
in/opt/dsf2/
to keep things separate but also tried theconfig2.json
. As neither of them worked I also tried to start the first (regular) DCS instance withsudo systemctl start duetcontrolserver -c /opt/dsf/conf/config.json
but it returns:
systemctl: invalid option -- 'c'
Are you sure this works, or do I need to duplicate something else as well?
I managed to start one instance on spi4, but figured spi1 und 4 don't work together - will need to search for an alternate wiring scheme I guess...
-
@chrishamm
Managed to rewire to spi3 and have spi0 and spi3 running at the same time now. So just need to figure out how to start the second DCS -
@benecito You need to duplicate the service file and edit it (/usr/lib/systemd/system/duetcontrolserver.service) to start with a different config. Same applies to the duetwebserver service.
-
@chrishamm all right - duplicated both of them. Do I need to edit anything but line 6?
[Unit] Description=Duet Control Server StartLimitIntervalSec=0 [Service] ExecStart=/opt/dsf2/bin/DuetControlServer TimeoutStopSec=15 Restart=always Type=notify User=dsf Group=dsf UMask=0002 CapabilityBoundingSet=CAP_SYS_PTRACE CAP_DAC_READ_SEARCH CAP_SYS_TIME AmbientCapabilities=CAP_SYS_PTRACE CAP_DAC_READ_SEARCH CAP_SYS_TIME [Install] WantedBy=sysinit.target
-
@benecito It won't work that way, because DCS defaults to
/opt/dsf/conf/config.json
. UseExecStart=/opt/dsf/bin/DuetControlServer -c /opt/dsf2/conf/config.json
instead. There is no need to copy the entire dsf directory but just
conf
andsd
in it, although it should work nevertheless. You'll need to edit the second duetwebserver service in a similar way, too. -
@chrishamm unfortunately it still does not work for me...
Also can't really find anything helpful in there.pi@CR-3D-Server:~ $ sudo systemctl start duetcontrolserver2 Job for duetcontrolserver2.service failed because the control process exited with error code. See "systemctl status duetcontrolserver2.service" and "journalctl -xe" for details. pi@CR-3D-Server:~ $ systemctl status duetcontrolserver2.service ā duetcontrolserver2.service - Duet Control Server Loaded: loaded (/lib/systemd/system/duetcontrolserver2.service; disabled; vendor preset: enabled) Active: activating (start) since Wed 2023-05-03 19:00:23 CEST; 1s ago Main PID: 14140 (DuetControlServ) Tasks: 9 (limit: 3597) CPU: 907ms CGroup: /system.slice/duetcontrolserver2.service āā14140 /opt/dsf/bin/DuetControlServer -c /opt/dsf/conf/config2.json May 03 19:00:23 CR-3D-Server systemd[1]: Starting Duet Control Server... May 03 19:00:24 CR-3D-Server DuetControlServer[14140]: Duet Control Server v3.4.1 May 03 19:00:24 CR-3D-Server DuetControlServer[14140]: Written by Christian Hammacher for Duet3D May 03 19:00:24 CR-3D-Server DuetControlServer[14140]: Licensed under the terms of the GNU Public License Version 3 May 03 19:00:24 CR-3D-Server DuetControlServer[14140]: [info] Settings loaded pi@CR-3D-Server:~ $ journalctl -xe May 03 19:00:57 CR-3D-Server systemd[1]: duetcontrolserver2.service: Failed with result 'exit-code'. āā Subject: Unit failed āā Defined-By: systemd āā Support: https://www.debian.org/support āā āā The unit duetcontrolserver2.service has entered the 'failed' state with result 'exit-code'. May 03 19:00:57 CR-3D-Server systemd[1]: Failed to start Duet Control Server. āā Subject: A start job for unit duetcontrolserver2.service has failed āā Defined-By: systemd āā Support: https://www.debian.org/support āā āā A start job for unit duetcontrolserver2.service has finished with a failure. āā āā The job identifier is 180062 and the job result is failed. May 03 19:00:57 CR-3D-Server systemd[1]: duetcontrolserver2.service: Scheduled restart job, restart counter is at 2629. āā Subject: Automatic restarting of a unit has been scheduled āā Defined-By: systemd āā Support: https://www.debian.org/support āā āā Automatic restarting of the unit duetcontrolserver2.service has been scheduled, as the result for āā the configured Restart= setting for the unit. May 03 19:00:57 CR-3D-Server systemd[1]: Stopped Duet Control Server. āā Subject: A stop job for unit duetcontrolserver2.service has finished āā Defined-By: systemd āā Support: https://www.debian.org/support āā āā A stop job for unit duetcontrolserver2.service has finished. āā āā The job identifier is 180128 and the job result is done. May 03 19:00:57 CR-3D-Server systemd[1]: Starting Duet Control Server... āā Subject: A start job for unit duetcontrolserver2.service has begun execution āā Defined-By: systemd āā Support: https://www.debian.org/support āā āā A start job for unit duetcontrolserver2.service has begun execution. āā āā The job identifier is 180128. lines 3564-3600/3600 (END)
this is my duetcontrolserver2.service:
[Unit] Description=Duet Control Server StartLimitIntervalSec=0 [Service] ExecStart=/opt/dsf/bin/DuetControlServer -c /opt/dsf/conf/config2.json TimeoutStopSec=15 Restart=always Type=notify User=dsf Group=dsf UMask=0002 CapabilityBoundingSet=CAP_SYS_PTRACE CAP_DAC_READ_SEARCH CAP_SYS_TIME AmbientCapabilities=CAP_SYS_PTRACE CAP_DAC_READ_SEARCH CAP_SYS_TIME [Install] WantedBy=sysinit.target
-
@benecito That log doesn't show quite a lot. Please run
journalctl -u duetcontrolserver2 -ef
and post the bit that keeps repeating. It may be a good idea to share your second config file as well (config2.json). -
@chrishamm Sorry for the delay - was out of office yesterday.
I figured one part out: I messed up the SPI addresses in the config file
May 03 20:35:20 CR-3D-Server systemd[1]: duetcontrolserver2.service: Main process exited, code=exited, status=74/IOERR May 03 20:35:20 CR-3D-Server systemd[1]: duetcontrolserver2.service: Failed with result 'exit-code'. May 03 20:35:20 CR-3D-Server systemd[1]: Failed to start Duet Control Server. May 03 20:35:20 CR-3D-Server systemd[1]: duetcontrolserver2.service: Scheduled restart job, restart counter is at 6981. May 03 20:35:20 CR-3D-Server systemd[1]: Stopped Duet Control Server. May 03 20:35:20 CR-3D-Server systemd[1]: Starting Duet Control Server... May 03 20:35:20 CR-3D-Server DuetControlServer[26915]: Duet Control Server v3.4.1 May 03 20:35:20 CR-3D-Server DuetControlServer[26915]: Written by Christian Hammacher for Duet3D May 03 20:35:20 CR-3D-Server DuetControlServer[26915]: Licensed under the terms of the GNU Public License Version 3 May 03 20:35:21 CR-3D-Server DuetControlServer[26915]: [info] Settings loaded May 03 20:35:21 CR-3D-Server DuetControlServer[26915]: [info] Environment initialized May 03 20:35:21 CR-3D-Server DuetControlServer[26915]: [fatal] Failed to open IO device: Error 2. Can not open SPI device file '/dev/spidev4.0'. May 03 20:35:21 CR-3D-Server systemd[1]: duetcontrolserver2.service: Main process exited, code=exited, status=74/IOERR May 03 20:35:21 CR-3D-Server systemd[1]: duetcontrolserver2.service: Failed with result 'exit-code'. May 03 20:35:21 CR-3D-Server systemd[1]: Failed to start Duet Control Server. May 03 20:35:21 CR-3D-Server systemd[1]: duetcontrolserver2.service: Consumed 1.017s CPU time. May 03 20:35:21 CR-3D-Server systemd[1]: duetcontrolserver2.service: Scheduled restart job, restart counter is at 6982. May 03 20:35:21 CR-3D-Server systemd[1]: Stopped Duet Control Server. May 03 20:35:21 CR-3D-Server systemd[1]: duetcontrolserver2.service: Consumed 1.017s CPU time. May 03 20:35:21 CR-3D-Server systemd[1]: Starting Duet Control Server... May 03 20:35:21 CR-3D-Server DuetControlServer[26968]: Duet Control Server v3.4.1 May 03 20:35:21 CR-3D-Server DuetControlServer[26968]: Written by Christian Hammacher for Duet3D May 03 20:35:21 CR-3D-Server DuetControlServer[26968]: Licensed under the terms of the GNU Public License Version 3 May 03 20:35:22 CR-3D-Server DuetControlServer[26968]: [info] Settings loaded May 03 20:35:22 CR-3D-Server DuetControlServer[26968]: [info] Environment initialized May 03 20:35:22 CR-3D-Server DuetControlServer[26968]: [fatal] Failed to open IO device: Error 2. Can not open SPI device file '/dev/spidev4.0'.
but hat SPI 3 enabled.
Figured out one or two more things but am stuck at starting DWC now
[Unit] Description=Duet Web Server Wants=duetcontrolserver.service After=network.target duetcontrolserver.service [Service] WorkingDirectory=/opt/dsf2/sd/www ExecStart=/opt/dsf/bin/DuetWebServer --SocketPath /run/dsf/dcs2.sock --urls http://*:8080 TimeoutStopSec=15 Type=notify User=dsf Group=dsf CapabilityBoundingSet=CAP_NET_BIND_SERVICE AmbientCapabilities=CAP_NET_BIND_SERVICE [Install] WantedBy=multi-user.target
and the corresponding config2.json:
{ "AutoUpdateFirmware": true, "PluginSupport": true, "RootPluginSupport": false, "PluginsFilename": "/opt/dsf/conf/plugins.txt", "LogLevel": "info", "SocketDirectory": "/run/dsf", "SocketFile": "dcs2.sock", "StartErrorFile": "/run/dsf/dcs.err", "Backlog": 4, "SocketPollInterval": 2000, "BaseDirectory": "/opt/dsf/sd2", "PluginDirectory": "/opt/dsf/plugins", "NoTerminateOnReset": false, "HostUpdateInterval": 4000, "MaxMessageAge": 60, "SpiDevice": "/dev/spidev3.0", "SpiBufferSize": 8192, "SpiTransferMode": 0, "SpiFrequency": 8000000, "SpiConnectTimeout": 500, "SpiTransferTimeout": 500, "SpiConnectionTimeout": 4000, "MaxSpiRetries": 3, "GpioChipDevice": "/dev/gpiochip0", "TransferReadyPin": 27, "BufferedPrintCodes": 32, "BufferedMacroCodes": 16, "MaxBufferSpacePerChannel": 1536, "MaxCodeBufferSize": 256, "MaxMessageLength": 4096, "FirmwareComments": [
but also tried
[Unit] Description=Duet Web Server Wants=duetcontrolserver.service After=network.target duetcontrolserver.service [Service] WorkingDirectory=/opt/dsf2/sd/www ExecStart=/opt/dsf/bin/DuetWebServer -c /opt/dsf/conf/http2.json TimeoutStopSec=15 Type=notify User=dsf Group=dsf CapabilityBoundingSet=CAP_NET_BIND_SERVICE AmbientCapabilities=CAP_NET_BIND_SERVICE [Install] WantedBy=multi-user.target
with
{ "Logging": { "LogLevel": { "Default": "Information" } }, "Kestrel": { "Endpoints": { "Http": { "Url": "http://*:8080" } } }, "KeepAliveInterval": 30, "SessionTimeout": 8000, "ModelRetryDelay": 5000, "UseStaticFiles": true, "DefaultWebDirectory": "/opt/dsf/sd2/www", "MaxAge": 3600, "SocketPath": "/var/run/dsf/dcs2.sock", "WebSocketBufferSize": 8192 }
both fail with
pi@CR-3D-Server:~ $ systemctl status duetwebserver2.service ā duetwebserver2.service - Duet Web Server Loaded: loaded (/lib/systemd/system/duetwebserver2.service; disabled; vendor preset: enabled) Active: failed (Result: signal) since Fri 2023-05-05 10:29:11 CEST; 5s ago Process: 4310 ExecStart=/opt/dsf/bin/DuetWebServer -c /opt/dsf/conf/http2.json (code=killed, signal=ABRT) Main PID: 4310 (code=killed, signal=ABRT) CPU: 1.121s May 05 10:29:11 CR-3D-Server DuetWebServer[4310]: at Microsoft.AspNetCore.Hosting.GenericWebHostService.StartAsync(CancellationToken cancellationToken) May 05 10:29:11 CR-3D-Server DuetWebServer[4310]: at Microsoft.Extensions.Hosting.Internal.Host.StartAsync(CancellationToken cancellationToken) May 05 10:29:11 CR-3D-Server DuetWebServer[4310]: at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.RunAsync(IHost host, CancellationToken token) May 05 10:29:11 CR-3D-Server DuetWebServer[4310]: at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.RunAsync(IHost host, CancellationToken token) May 05 10:29:11 CR-3D-Server DuetWebServer[4310]: at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.Run(IHost host) May 05 10:29:11 CR-3D-Server DuetWebServer[4310]: at DuetWebServer.Program.Main(String[] args) in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetWebServer/Program.cs:line 25 May 05 10:29:11 CR-3D-Server systemd[1]: duetwebserver2.service: Main process exited, code=killed, status=6/ABRT May 05 10:29:11 CR-3D-Server systemd[1]: duetwebserver2.service: Failed with result 'signal'. May 05 10:29:11 CR-3D-Server systemd[1]: Failed to start Duet Web Server. May 05 10:29:11 CR-3D-Server systemd[1]: duetwebserver2.service: Consumed 1.121s CPU time.
-
@benecito Are you certain that /dev/spidev4.0 exists? Perhaps you need /dev/spidev3.0 instead.
It looks like the
--urls
parameter doesn't work as documented, I just checked this. You need to change the second service file to something likeExecStart=ASPNETCORE_URLS="http://*:8080" /opt/dsf/bin/DuetWebServer --SocketPath /run/dsf/dcs2.sock
. Also, it looks like theKestrel
section in/opt/dsf/conf/http.json
overrides theASPNETCORE_URLS
setting. I suggest you remove that section in that file and changeduetwebserver.service
(preferably after copying it to/etc/systemd/system
first to avoid issues on upgrade) toExecStart=ASPNETCORE_URLS="http://*:80" /opt/dsf/bin/DuetWebServer
instead. -
@chrishamm this throws
May 05 11:20:26 CR-3D-Server systemd[1]: /lib/systemd/system/duetwebserver2.service:8: Neither a valid executable name nor an absolute path: ASPNETCORE_URLS=http://*:8080 May 05 11:20:26 CR-3D-Server systemd[1]: duetwebserver2.service: Unit configuration has fatal error, unit will not be started.
-
@benecito Sorry, systemd requires a different format for environment variables:
Environment=ASPNETCORE_URLS="http://*:8080" ExecStart=/opt/dsf/bin/DuetWebServer --SocketPath /run/dsf/dcs2.sock
-
@chrishamm
Hey,
finally managed to get to it again and without printers connected it is working right now.
Now just need to sort things in my head and make sure it also works fine with two machines actually printing at the same time.You mentioned I should copy some files to be safe in case of an update here:
@chrishamm said in Connecting multiple duets to one SBC:
Also, it looks like the
Kestrel
section in/opt/dsf/conf/http.json
overrides theASPNETCORE_URLS
setting. I suggest you remove that section in that file and changeduetwebserver.service
(preferably after copying it to/etc/systemd/system
first to avoid issues on upgrade) toExecStart=ASPNETCORE_URLS="http://*:80" /opt/dsf/bin/DuetWebServer
instead.Can you please point out again which files you would recommend to copy where?
Over all I created:
/etc/systemd/system/duetcontrolserver2.service
/etc/systemd/system/duetwebserver2.service
/opt/dsf/sd2/ (as a duplicate of /opt/dsf/sd/)
/opt/dsf/conf/config2 .json (as a mostly duplicate of /opt/dsf/conf/config.json)and edited:
/opt/dsf/conf/config.json
/opt/dsf/conf/http.json
/etc/systemd/system/duetwebserver.serviceI assume the ones I edited but did not duplicate should be duplicated as well?
-
@benecito That structure sounds reasonable to me. The service files come from /usr/share/systemd/system AFAIR.
-
@chrishamm quick update (and question)
We finally finished the test setup with actual printers connected. Unfortunately on pretty much any print one of the looses it's connection with a "Waiting for transfer ready pin" message.
Right now the wires are about 25cm long but well away from any other cables. We're trying to rearrange the setup to be able to use shorter cables but not sure if that's actually the issue.Can it be somehow related to two SPI connections running at quite a bit of throughput on the same pi and thus some timing errors or so happening? In all cases the connection is back less than a second after.
Happy to hear any thoughts and maybe still get them running reliably! -
@chrishamm Any thoughts on this?
We now tried to run the Duets over SBC but print over USB. This went well so far but haven't run any long term tests.
Therefore to me it sounds like a timing issue related to the transfer ready pin with the increased throughput of printing over SBC.
Can you confirm if the USB print does not go trough the SBC connection back and forth?Still we would prefer to also print over SBC as we would have the whole ObjectModel available here.
-
@benecito Hard to say. Do you get any TfrRdy glitches in the M122 diagnostics? If yes, there is probably noise on the TfrRdy line causing the culprit. Try shielding the transfer cables and see if that makes a difference. If that doesn't work, consider trying out a different GPIO pin on the Pi side, perhaps even from a different gpiochip device if possible.
-
@chrishamm now I was able to reproduce this. It might be a little different this time as DWC showed as disconnected at first but then eventually came back to life.
That's the M122 diagnostics:
M122 === Diagnostics === RepRapFirmware for Duet 3 Mini 5+ version 3.4.5 (2022-11-30 19:41:16) running on Duet 3 Mini5plus WiFi (SBC mode) Board ID: N5HL0-0P6KL-K65J0-409N2-M612Z-7NY58 Used output buffers: 1 of 40 (27 max) === RTOS === Static ram: 103652 Dynamic ram: 99256 of which 204 recycled Never used RAM 34400, free system stack 118 words Tasks: SBC(ready,13.3%,434) HEAT(notifyWait,0.5%,326) Move(notifyWait,2.1%,265) CanReceiv(notifyWait,0.0%,942) CanSender(notifyWait,0.0%,336) CanClock(delaying,0.2%,341) TMC(notifyWait,11.4%,106) MAIN(running,58.4%,557) IDLE(ready,0.1%,30) AIN(delaying,13.9%,263), total 100.0% Owned mutexes: HTTP(MAIN) === Platform === Last reset 23:39:07 ago, cause: power up Last software reset at 2023-08-01 09:44, reason: User, GCodes spinning, available RAM 35960, slot 0 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task SBC Freestk 0 n/a Error status: 0x00 MCU revision 3, ADC conversions started 85147781, completed 85147780, timed out 0, errs 0 Step timer max interval 1490 MCU temperature: min 31.4, current 38.1, max 52.0 Supply voltage: min 23.4, current 23.8, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes Heap OK, handles allocated/used 99/8, heap memory allocated/used/recyclable 2048/106/0, gc cycles 0 Events: 0 queued, 0 completed Driver 0: standstill, SG min 0, read errors 0, write errors 0, ifcnt 24, reads 24846, writes 24, timeouts 0, DMA errors 0, CC errors 0 Driver 1: standstill, SG min 0, read errors 0, write errors 0, ifcnt 24, reads 24846, writes 24, timeouts 0, DMA errors 0, CC errors 0 Driver 2: standstill, SG min 0, read errors 0, write errors 0, ifcnt 24, reads 24845, writes 24, timeouts 1, DMA errors 0, CC errors 0, failedOp 0x6a Driver 3: standstill, SG min 0, read errors 0, write errors 0, ifcnt 24, reads 24846, writes 24, timeouts 0, DMA errors 0, CC errors 0 Driver 4: standstill, SG min 0, read errors 1, write errors 0, ifcnt 24, reads 24845, writes 24, timeouts 0, DMA errors 0, CC errors 0 Driver 5: not present Driver 6: not present Date/time: 2023-08-09 08:35:44 Cache data hit count 4294967295 Slowest loop: 56.65ms; fastest: 0.09ms === Storage === Free file entries: 10 SD card 0 not detected, interface speed: 0.0MBytes/sec SD card longest read time 0.0ms, write time 0.0ms, max retries 0 === Move === DMs created 83, segments created 56, maxWait 39571259ms, bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves 151579, completed 151579, hiccups 0, stepErrors 0, LaErrors 0, Underruns [3160, 0, 1], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0 Heater 1 is on, I-accum = 0.0 === GCodes === Segments left: 0 Movement lock held by null HTTP* is doing "M122" in state(s) 0 Telnet* is idle in state(s) 0 File is idle in state(s) 0 USB is idle in state(s) 0 Aux is idle in state(s) 0 Trigger* is idle in state(s) 0 Queue* is idle in state(s) 0 LCD is idle in state(s) 0 SBC is idle in state(s) 0 Daemon is idle in state(s) 0 Aux2 is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty === CAN === Messages queued 766304, received 0, lost 0, boc 0 Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 18 (min 18), ts 425738/0/0 Tx timeouts 0,0,425737,0,0,340565 last cancelled message type 4514 dest 127 === SBC interface === Transfer state: 5, failed transfers: 0, checksum errors: 0 RX/TX seq numbers: 545/545 SPI underruns 0, overruns 0 State: 5, disconnects: 2, timeouts: 2 total, 2 by SBC, IAP RAM available 0x0f1bc Buffer RX/TX: 0/0-0, open files: 0 === Duet Control Server === Duet Control Server v3.4.5 Code buffer space: 4096 Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0 Full transfers per second: 38.41, max time between full transfers: 190.0ms, max pin wait times: 40.1ms/1.4ms Codes per second: 2.74 Maximum length of RX/TX data transfers: 6836/368
And the end of the log file from the RepetierServer print should it be of any help:
Send:21:14:35.295: N160496 G1 X183.139 Y141.32 E14.18028 Send:21:14:35.295: N160497 G1 X183.746 Y141.494 E14.19944 Recv:21:14:35.338: ok Send:21:14:35.338: N160498 G1 X184.369 Y141.6 E14.2186 Recv:21:14:35.607: ok Send:21:14:35.607: N160499 G1 X185 Y141.636 E14.23776 Recv:21:14:35.693: ok Send:21:14:35.693: N160500 G1 X185.631 Y141.6 E14.25692 Recv:21:14:35.968: ok Send:21:14:35.968: N160501 G1 X186.254 Y141.494 E14.27608 Recv:21:14:36.003: ok Send:21:14:36.003: N160502 G1 X186.861 Y141.32 E14.29524 Exec:21:14:38.589: @getip Send:21:14:38.592: N160503 M117 192.168.187.49:3344 Recv:21:14:38.693: Lost connection to Duet (Timeout while waiting for transfer ready pin) Recv:21:14:38.693: Connection to Duet established Recv:21:14:38.696: start Send:21:14:38.696: N1 M110 Exec:21:14:59.348: @call RHRead timer30 "null" Mesg:21:15:09.696: Warning: Communication timeout - resetting communication buffer. Mesg:21:15:09.696: This means that a expected firmware response was not seen within the expected time. Mesg:21:15:09.696: The typical reason is a communication error and print should continue after the communication reset. Mesg:21:15:09.696: Connection status: Buffered:8, Manual Commands: 30, Job Commands: 0 Mesg:21:15:09.696: Buffer used:8 Enforced free byte:17 lines stored:1 Offl:21:54:53.881: Ignored (offline):M119 Offl:21:54:53.881: Ignored (offline):M119 Exec:21:54:53.881: @syncAckState Offl:21:54:53.881: Ignored (offline):M117 Finished Offl:21:54:53.881: Ignored (offline):M105 Offl:21:54:53.881: Ignored (offline):M115 Offl:21:54:53.881: Ignored (offline):M114 Offl:21:54:53.881: Ignored (offline):T0
Since it has now been reproduced I'll look into some rewiring. I don't think it's noise though as the SBC wire bundle right now goes trough mid air to rule that out and we also tried shielded ethernet cables for that exact reason.