Posts made by CarlosR

@dc42 Any alternatives? Thanks!

@dc42 Currently it is connected to an expansion board (Duet 3 Expansion TOOL1LC). Would it make a difference if I connect it to the main board (Duet 3 MB6XD)?

It is an analog sensor that works at 5V. Currently I have it working at 3.3V but planning to incorporate an ADC Daughter Board.

M308 S12 P'70.temp0' Y"linear-analog" A"Sensor1"

@dc42

I would like to get a value from a sensor that is connected to the board as often as possible.

I just reduced the ModelUpdateInterval variable in the /opt/dsf/conf/config.json file. I know this is not a good approach in terms of performance, but it's the best option I've found so far.

I also tried playing with the dsf-python project and the SubscribeConnection class, but I think the frequency is the same.

I also tried to dump the sensor values to a file using daemon.g, but writing a file is not efficient either.

Any other ideas I could try?

Ideally I would like to update this specific variable as much as possible (10ms, 20ms, 50ms... , whatever value that is the fastest) and the rest of the ObjectModel update it as default.

Thanks.

Hi everyone,

Is it possible to increase the ObjectModel update frequency? If so, how?

I realized the updates occur every 400ms, would be possible to reduce it to 100-200ms?

Thanks.

Hi,

I need some help with setting up the MQTT server from the configuration.
I would like to subscribe to a topic from a third party app and generate messages from the gcode files using the M118 commands.

Could you please help me with setting up the network config and MQTT server?

Kind regards.

@chrishamm Thank you so much!

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

1. Install @duet3d/connectors, @duet3d/objectmoddel and xhr2 package:

npm install @duet3d/connectors 
npm install @duet3d/objectmodel
npm install xhr2

2. Import XMLHttpRequest from xhr2 package in BaseConnector.js file

const XMLHttpRequest = require("xhr2");

3. Import WebSocket from ws package in RestConnector.js:

const WebSocket = require('ws');

Then everything work as normal.

Hi,

I'm trying to subscribe via websocket to the object model using a node.js client.

let objectModel = null;
  wsClientDuet.on("connectFailed", function (error) {
    console.log("Connect Error");
  });
  wsClientDuet.on("connect", (conn) => {
    connectionDuet = conn;
    console.log("Connected to Duet WebSocket Server");
    connectionDuet.on("error", function (error) {
      console.log("Connection Error");
    });
    connectionDuet.on("close", function () {
      console.log("Connection to Duet is closed");
    });
    connectionDuet.on("message", function (message) {
      console.log(message.utf8Data);
      if (message.utf8Data === "PONG\n") {
        return;
      }
      if (objectModel === null) {
        objectModel = message.utf8Data;
        console.log("Object model received");
        return;
      }
      let ack = "OK\n";
      connectionDuet.sendUTF(ack);
    });
  });
  setInterval(async () => {
    if (connectionDuet.connected) {
      let message = "PING\n";
      connectionDuet.sendUTF(message);
    }
  }, 5000);

  await wsClientDuet.connect(`url`, "");

The server is replying with PONG after the PINGS.
Also, the first object model is sent. But it seems the OK is not working since the server is not sending any patch.

Is there anything wrong in the code?

Thank you.

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

Hi all,

I'm trying to print an object with 2 tools. This is not relevant since it is the same if I remove the T1 part...

The problem is that the first few movements are very slow and also the tool makes weird movements, like stepping instead of doing "fluid movements".

Looking at the gcode, everything looks correct, I don't know why the speed is reduced...

After the starting movements, everything goes ok. But the printing is completly ruined due to the first movements.

wrong.gcode

@pcr Thank you! I will

Hi all,

Is it possible to mantain two versions of DWC coexisting?

The idea is to use the original DWC as an advanced GUI (for expert users), and also create a modified version that is simpler and prettier (for final users).

The plan is to serve each version in a different port, but my fear is if the data model will be shared correctly, if it will produce delays somehow, or if it will be incompatibilities.

DWC is very complex, and it is easier to remove GUI elements and change appearence from the original than adapt the original to what we want.

Thank you.

@gloomyandy

Just the same probe system.

But if we alternate G30 and G30 S-1 in RepRap, we get a good repeatability. G30 S-1 values between -0.010 and 0.010.

The problem is when running G30, and then multiple G30 S-1 which just report the stopped height without overwritting the z datum.

Hi all,

We noticed a weird behaviour related to the G30 command.

If we run a G30 to stablish the Z datum, and then multiple G30 S-1, each time the reported stop height value increases (0.010 -> 0.030 -> 0.040 -> 0.050-> 0.080 -> ... -> 0.120 ...). Sometimes the value decreases a bit (0.040 -> 0.030), but the tendency is to increase. If we run again G30, the values seem to be reset and they start again increasing from 0.010 when multiple G30 S-1 sent.

Furthermore, if we loop multiple G30 S-1, and induce a huge error in one of them (introducing an object to make it fail and stop at 0.3 height value), then the following G30 S-1 report similar values to 0.3mm instead of values similar to 0.010 which is the error deviation of the probe.

We think this issue is producing wrong values when creating the heightmap. We tested the probe into another environment (Marlin) and the repeatability was almost perfect (~0.01 deviation).

Anyone else noticed something similar?

Thanks in advance.

; Z probe config
M558 P8 C"!io3.in" A1 H12 R0.5 F800 T4000      ; set Z probe type and the dive height + speeds
G31 X0 Y0 Z0               	               ; set Z probe trigger value, offset and trigger height

All G30 and G30 S-1 are sent at X0 Y0 position.

FW version: 3.4.beta5

@t3p3tony

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

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

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

@t3p3tony

We set the machine limits after measuring the tool lenght (z datum and bed comp already applied).

We move down the nozzle until trigger a switch, and when triggered we stablish the machine limit with

M208 Z{move.axes[2].machinePosition} S1

During the process, we disable the axis limits, and the machine position is usually a negative value, so the limits are -8.5:88.2 or something similar for the tool 0.

The machine -8.5 position always will be the virtual 0 when the tool is enabled. And the max limit will always be the same one measured the Z datum and applied the Bed comp.

Hi,

We have managed to have the bed compensation working in our environment (we had some problems as it is a complex printing system with 3 different nozzles with independant motors, and tool lenght calibration).

Now it seems to be working fine (as it moves de Z axis regarding the heightmap).

However, we noticed that the applied compensation is not enough.

Example:

• If we are at X=0, Y=0, the bed comp. is 0.000, and the nozzle is touching the bed correctly Z=0.
• If we move to X=100, Y=60, the bed comp. is 0.620, and the nozzle touches the bed at Z=0.3 aprox.
• If we move to X=-100, Y-60, the bed comp. is -0.200 (notice the negative), the nozzle doesn't touch the bed at Z=0 (it stays at real 0.1 height aprox).

It seems that the algorithm doesn't apply the correct steps to the motor. Is that possible? And how can we fix it.

Our fw version is 3.4.0beta4

Thank you,
Carlos.

@o_lampe That would be amazing, it is what are we looking for.

@dc42

Thank you,

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

Hello,

Just a quick question:

Is it possible to query the actual bed compensation value from the Object model?

Thanks in advance.

Hi all,

We are trying to perform the bed compensation in our machine.

After running the Z home routine, we stablish the Z datum = 0, and we lift the nozzle until trigger de endstop. We update the axis limits with the machine position value when it reaches the endstop (the axis range is from 0 to 89 aprox).

Then we load the heightmap at X0 Y0 (the position where we perform the Z probing on homing).

The problem is that the bed is higher in other positions.

If the nozzle isn't in the axis limit, the bed compensation works properly as the nozzle is lifted automatically by the compensation values (keeping the same machine position values).

But if the nozzle is in the Z axis limit, the Z machine position is still 89 (+ bed comp: 0.5), but the real range is 88.5 so the nozzle touches the bed.

We don't know if we are understanding the behaviour correctly...

Our fw version is 3.4.beta2