Connecting multiple duets to one SBC

chrishamm

@benecito It won't work that way, because DCS defaults to /opt/dsf/conf/config.json. Use

ExecStart=/opt/dsf/bin/DuetControlServer -c /opt/dsf2/conf/config.json

instead. There is no need to copy the entire dsf directory but just conf and sd in it, although it should work nevertheless. You'll need to edit the second duetwebserver service in a similar way, too.

benecito

@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

chrishamm

@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).

benecito

@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.

chrishamm

@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 like ExecStart=ASPNETCORE_URLS="http://*:8080" /opt/dsf/bin/DuetWebServer --SocketPath /run/dsf/dcs2.sock. Also, it looks like the Kestrel section in /opt/dsf/conf/http.json overrides the ASPNETCORE_URLS setting. I suggest you remove that section in that file and change duetwebserver.service (preferably after copying it to /etc/systemd/system first to avoid issues on upgrade) to ExecStart=ASPNETCORE_URLS="http://*:80" /opt/dsf/bin/DuetWebServer instead.

benecito

@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.

chrishamm

@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

benecito

@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 the ASPNETCORE_URLS setting. I suggest you remove that section in that file and change duetwebserver.service (preferably after copying it to /etc/systemd/system first to avoid issues on upgrade) to ExecStart=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.service

I assume the ones I edited but did not duplicate should be duplicated as well?

chrishamm

@benecito That structure sounds reasonable to me. The service files come from /usr/share/systemd/system AFAIR.

benecito

@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!

benecito

@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.

chrishamm

@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.

benecito

@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.

PrintMan

@benecito have you tried DuetPrintFarm? I'm waiting for their feature

benecito

@PrintMan what's DuetPrintFarm?

infiniteloop

@benecito said in Connecting multiple duets to one SBC:

what's DuetPrintFarm?

This: https://github.com/Duet3D/DuetPrintFarm

benecito

@infiniteloop Interesting. I'll take a look, but I think not what we are aiming for right now.

benecito

@chrishamm
Can you confirm that a USB print does not go trough the SBC connection back and forth?

chrishamm

@benecito I'm sorry, but I don't get what you mean by that.

benecito

@chrishamm no worries!

To narrow things down we originally wanted to go back to a usb connection but stopped in the middle.
The Duet was still connected via SBC (so no SD card in the duet) but also had a usb cable from the pi running RepetierServer (the external printing source) to the duet.
We noticed that this appears to work just fine and ran a few test prints.

So basically what we have now ist the duet connected via SBC to the pi and RepetierServer communicating with the duet via USB for status updates and printing (instead of the server being connected to the duet SBC socket on the pi). Obviously this would not make sense if the commands the duet receives over usb get sent back and forth trough the SBC connection, but as it has been going fine so far I assume they are not.