Topics created by CarlosR

@CarlosR What Duet board and firmware version are you running? Send M122 and post the response. How is it currently configured?

I haven't set up MQTT myself, so I don't have any experience. Can you look at the documentation here, and see how far that gets you:
https://docs.duet3d.com/User_manual/Reference/Gcodes#m5864-configure-mqtt-client
https://github.com/Duet3D/MQTT-WPA2-Enterprise-Demo

Have a look at some of the forum threads on MQTT too: https://forum.duet3d.com/search?term=Mqtt&in=titles

Ian

@chrishamm Thank you so much!

It didn't work indeed in standalone nodejs. However, that was easy to fix (in case anyone is interested).

Install @duet3d/connectors, @duet3d/objectmoddel and xhr2 package: npm install @duet3d/connectors npm install @duet3d/objectmodel npm install xhr2 Import XMLHttpRequest from xhr2 package in BaseConnector.js file const XMLHttpRequest = require("xhr2"); Import WebSocket from ws package in RestConnector.js: const WebSocket = require('ws');

Then everything work as normal.

@Phaedrux sorry fot the late answer, I just solved the problem.

The printheads boards weren't updated to 3.4.3 but the main board was.

@pcr Thank you! I will

@mikedc Glad to hear that! Still haven't tested in our HW, but looks promising. The 1XD boards would be the same than 3HC in CAN delays related so I hope this solution also works with them.

@t3p3tony

M208 reports the machine limits regardless the actual position. These limits that are -8.5:88.2 (Z axis).

If I move the nozzle down to Z0 at X0, Y0:
M114 reports user position as Z=0, machine position as Z-8.5 (which is the limit), and the bed comp value is 0.000. The nozzle is well positioned (almost touching the bed)

If I don't lift the nozzle and move to a position where the bed comp is -0.2 (that means the bed is lower in that point)
M114 still reports user position as Z=0 (because i didn't lift it), machine position still Z-8.5, and bed comp. is -0.200. However, the nozzle is not touching the bed as it should, it is 0.1mm above (it compensates -0.1 instead of -0.2).

I can't run more tests until Thursday, but I will try to provide more info about the behaviour when possible.

Thanks.

@dc42

Thank you,

And is there a way to calculate the bed compensation value for a given X,Y position?

@fcwilt Yes, it's the way we do it. Our HRP when we homing is the bed center (X0 Y0).

@dc42

Do you mean by overwritting the M208?

If I understand correctly, the new minimum should be the previous minimum (in relation with the HRP) + tool offset.

I'mma try it out.

Thank you for your comment.

@carlosr do the following commands work:

M584 X40.0
M569 P40.0

Also, please can you construct a simple config.g file that reproduces the problem.

@carlosr you're probing a separate switch to determine the tool length, correct?
or are you using the same switch that you probe the bed with to get Z0?

using my CNC as an example, I know much touch plate for calibrating tool length is 19.7mm above my z datum, so I can work out the tool offset by using the Z stopped height minus the 19.7mm

I'm just trying to work out where the tool length switch is in relation to Z0

@carlosr it's standard behaviour that after a tool change, all coordinates get restored to the position immediately prior to the tool change. This is because we can't assume that the slicer will send a command to travel to the correct coordinates for all axes after it commands a tool change.

The way it does this is to save the position in restore point 2 at the start of the tool change, and restore the position to the contents of restore point 2 at the end. So you could modify the behaviour by using G60 within your tool change files to change the coordinates stored in restore point 2.

@dc42 OK, thanks.

Temperatures aren't our concern now. Were still far from heat up or print despite having all the hardware finished

We saw some temp variations/inaccuracy with 3.3 and 3.4b2 during previous tests.

@carlosr @jay_s_uk is right I developed the Node-Red nodes with functionality specifically to intercept specially formatted M291 msgs which can be embedded in your gcode, or you can setup a monitor to watch for specific machine model variable changes. If you give me a few more details about what conditions will trigger your event, I may be able to help further.

If you want to develop your own application from scratch have a look at the Duet api's on the Duet Git repo. I used them a while ago to create a rules/event based MQTT messaging system (which you can also find on my repo, and reviewing the code may help you get to your desired goal quicker).

Both of these approaches work on the principle of establishing a unix/web socket subscription to Duet and then parsing the updates as they arrive.