Topics created by qurt

@qurt The affected SBC is outdated and does not support rr_ protocol emulation yet. Upgrade it using apt and then try again. See https://docs.duet3d.com/en/User_manual/Machine_configuration/DSF_RPi#installing-updates

Also note that it would be better to use the native REST protocol in SBC mode unless you need to deal with boards in standalone mode, too. See https://github.com/Duet3D/DuetSoftwareFramework/wiki/REST-API for further information.

@droftarts You can nest other instances of DWC with BtnCmd's remote source panel, but I'm not sure how optimised it would be (I only have 2 printers to test with), I don't think it really meets the criteria though.
Screenshot_20240719_143713-1.png

Otherwise its possible to pull a unified data dashboard togther with NodeRed & NodeDSF

Also have a look at this thread

What version of RRF and DWC?

In the Video Duet Web Control 3.4.6 is used (but I think I saw it also in the latest version.)
What browser? Chrome
What operating system is the browser running on? Default Raspbian (octoprint image)
What exactly did you do before the slider started moving (I don't see any interaction with the slider in the video)? Just dragging the slider. After releasing the slider was moving up and down. It doesn't always happen. Therefore this video was taken afterwards.

@chrishamm Thats actually a prety good idea: I can image that for some reasons there happens no explicit touchend event. (not sour where this touch end event is generated)

Yes I believe wget should work, as well as FTP. If you search the forum for wget you may find some examples.

@qurt I think it would need to be modified before it gets to the command queue, as it's very difficult to modify anything once it gets there. For more information on how the command queue works, see https://docs.duet3d.com/en/User_manual/Reference/Gcodes#command-queueing

You can shorten the command queue for quicker response to changes that you are streaming in, using M595.

But the shorter the queue, the more likely buffer starvation will occur. If you are streaming Gcode over USB, see Printing over USB connection for other limitations.

Ian

@qurt You could use the HTTP requests API and talk to the Duet Board via LAN. https://github.com/Duet3D/RepRapFirmware/wiki/HTTP-requests

@droftarts Do you need quicker cycletimes than 0.33 to 5ms?
And yes this is the entire purpose of this question.

@qurt the time is passed by Duet Web Control to the Duet when it connects. If you don't normally have an instance of DWC connected to the Duet, you could use another device that has a real-time clock either to send rr_connect messages over the HTTP interface, or to send M905 messages to the Duet over USB or serial.

@qurt If you are running long cables in an industrial environment you should be taking appropriate precautions with shielding. That applies to the CAN cables but also to cables such as temperature sensors etc. Once advantage of running CAN to areas like the tool head, over running the motor drivers, heater cables and temperature sensors, is there is less wiring exposed to interference (or generating interference) over long distances.

@qurt we occasionally measure the maximum step rates supported by Duet main and expansion boards and publish them at https://docs.google.com/spreadsheets/d/1AWA1wLbOaYzxzdQa5LRZvn9rgEk2BuluHy6-_OnD6FY/edit?usp=sharing.

In RRF all motion calculations are done on the Duet. Motion control and communication with expansoio boards are real-time task once the moves have been melded and finalised, and is therefore best done by a real-time processor running a real-time operating system. When Duet+RRF are used in SBC mode, the parsing of GCode commands is done on the SBC so that that Duet is relieved of some non-real-time tasks.