Hi,

I am interested in integrating the Duet's status in Cura's monitor tab.
I'm looking at exposing most of the functions from the DWC to Cura.

What I got so far is that DWC sends HTTP GET and POST requests to ReprapFirmware and diplays it through a web interface.

Efficiency-wise it probably wouldn't make much sense to scrape the values from the interface and display them in Cura, but rather query them the same way the web interface does it.

So far, DWC's list of HTTP requests lists the requests currently used by the web interface, so I wanted to know whether there is a list of ALL requests that the RRfirmware supports? I found this list, but is this all?

Also, do I need to constantly re-load/"re-poll" frequently changing values, such as eg the extruder tempt? Or is there an easier way of keeping the displayed values up-to-date?

Thanks for all the input,
-h

Hi community,

I'm looking to log data from a sensor that is connected to a duet board into a file and time-stamp it.
Upon processing that data, the program should adjust printing parameters mid-print.

My aim is to get everything done via dsf-python.

I found this example for how to subscribe to the objetc model: https://github.com/Duet3D/dsf-python/blob/main/examples/subscribe_object_model.py

• Is there a way to subscribe only to a single sensor value?
• Is there a way to actively poll every eg 250 ms, or do I have to wait to be updated?
• Is there a way to always run this script in the background when a print is executed, or do I always need to manually start it (or start the script via a custom M code?)
• Are there more examples online of custom py-dsf scripts?

Pointers into any direction are greatly appreciated.
Thank you!

Thanks @chrishamm, appreciate your reply. Super useful, as always!

@Falcounet thanks, looking forward to hearing from you.

I'll give this a go in the next week and will reply back!

@dc42 said in Change name of 1LC or Sammy board in Firmware:

That is where you would need to change the name of the file that is installed when you command a firmware update or a CAN reset.

Awesome, thanks, I will try it!

Hey,

I'm looking for a way for the 1LC (or sammy) to communicate a pre-defined code (name/number) to the main board when asked via gcode.

I was thinking of slightly modifying the bootloader so that it has this info permanently stored in the chip.
It would then inform me of its "code" by giving each 1LC/SAMMY a custom name and then querying that name via

M122 B11

This should return

Diagnostics for board 11: Duet TOOL1LC firmware version 3.3beta2+1 (2021-03-20 14:03:00) Bootloader ID: SAMC21 bootloader version 2.3 (2021-01-26b1)

Instead, my plan would be that it returns:
ID: Custom_code_1 version 1.1 (_date_)

My question is: Is that the best way to implement this?
Is there an easier way than creating a custom firmware, similar to updating the canbus address via gcode?

And in case that's the way to go, could someone please point me to where this info is encoded? I was looking through the Github repo for Sammy board to find where the info would be saved for this board, but couldn't find the location

@o_lampe It has to be well-timed (position & intensity), but I'm not continuously using the output device for longer than a couple of minutes if that makes a difference.

On/off is not ideal, as I cannot use the preparation scheme of exisitng slicers that would allow me to follow G1 Sx commands.

@oliof yes, exactly!

Is it really related to data rates of the CAN-bus or is it simply not yet implemented?

thanks for all your support.

my main use-case is to have the laser as a modular printhead and having a printer base that I can easily re-configure to fit either 1, 2 or more laser, or combine it with other extrusion modules.
There is also a heating and cooling system present. It's a low-power laser that is not used for cutting/engraving, but has a special applications.

Therefore, I was looking to have more than 1 laser pin, and moreover, having this pin on a toolboard.

Is there perhaps a way to re-map the mainboard pin?

eg: if pin(main) is high, set pin(toolboard) to high?

@jay_s_uk that's odd, do you know the reason?

Is there any way to circumvent this?

On the same topic:
Definingn the port with M452 ONLY allows to define the laser head on the mainboard.

The moment I move this pin to a 1LC, I get

Error: M452: Port must be on main board

Why is that? Can I only connect a laser PWM to the main board?

@jay_s_uk
Thanks for your input.
I see. Yes, I already thought that this would be the only option to move forward.

If anyone has a more elegant solution, I'd still behappy to hear it.

Hi everyone,

With the tool-changing capabilities of the Duet3D firmware, we're building a printer with multiple laser heads and extruders.

We already figured out that we can swap between fff mode and laser mode when switching between the tools, but I'm struggling to define more than 1 laser head.

According to the laser config doc:

this enables Laser mode, on out9, with max intensity being 255, and a PWM frequency of 200

M452 C"out9" R255 F200

then, during printing, this controls the laser based on E values in G1

M571 P"out9" F200 S255

I'm looking for a way to have multiple M452 commands and "tie" them to a tool definition, similar to the way I define my other tools

whenever I perform a tool-change, Duet should know which laser head to turn on when following G1 commands.

what am I not seeing? any pointers are greatly appreciated!

@dainon
Thanks for the write-up, that's an interesting solution.
Can you tell me how exactly a reverse proxy circumvents the CORS issue?
How exactly does the relaying part work?

At the moment, our website is hosted on a domain, in our case with an ingress tunnel from cloudflare.

The thing is.... I'm not even sure what is causing the CORS, as I AM connecting to the device from the same location (ie origin) after reset.
I'm trying to understand where the error stems from and how your implementation is different?

@chrishamm is there a way to completely disable CORS on the RPi, without gcode? Is it possible to change in the server code?
There used to be a way to hard-code it by editing UseCors in /opt/dsf/conf/http.json from false to true.
I also tried that to no avail.
Is there a different way to change the server headers?

On a related basis, where do I find the logs of these CORS events server-side?
Perhaps this can help debugging the issue further?

Thank you everyone for the feedback!
Best,
-h

@chrishamm
thanks chris for linking the docs, I must have missed them.

I can now disconnect and connect to previous sessions by storing the sessionkey.

However, as soon as I reset the printer (M112, M999) and I try to reconnect to the websocket again, I get a CORS error

The config.g, as well as the dsf-config.g both have M586 C"*" as the first line.

Funnily enough, if I'm fast enough, right after hitting reset, I disconnect and re-connect directly, then I can re-initiate the websocket, but not send any commands, as all GET requests result in a CORS error!

Is there a different way of disabling the CORS headers?
Or a different way of dealing with this kind of behaviour?
I spent the past 10 hours trying to circumvent this problem to no avail.