I need to trigger a http request to call a service from an application backend I'm developing. This request is suposed to be triggered multiple times during the printing process to control external devices and processes.

I know this topic had been treated previously in this forum, but almost a year ago.

Just wondering if any advances in that.

I don't think Telnet would be a solution regarding the security, as I would need to integrate a telnet client inside the application and I'm not familiar with this technology.

Thanks in advance.

@jay_s_uk Yes, it seems to be correctly connected

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

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