Topics created by DDD

@DDD bear in mind that C++ for embedded processors is not the same as C++ for desktop machines and servers. In particular, use of dynamic memory is minimised, so most of the STL classes are avoided.

@dc42 After looking at my code, I was querying the wrong probe. The sensors.probe[1].value works, the problem was between the keyboard and the chair.

However, using the Object model plugin, no probe value gets updated at sensors.probes[#].value[0]. Even when meta-commands and the status board shows the right value.

Add: The JSON file gets updated but requires refreshing the website for the values to be updated into the Object model plugin.

@hauschka

Can you tell me how exactly a reverse proxy circumvents the CORS issue?

CORS, which is a security feature, is upheld by the browser to maintain that a client is requesting the resources from the same origin. In the case of writing your own website for Duet you now have 2 origins: (A) Duet3D Web Server, (B) Your Custom Web Server. Each of these is it's own origin. As a client using (B), you request pages/content from (B) which becomes B-Client in this example. Your code on the client side sends requests to from B-Client to A, which is Cross-Origin Resource Sharing (CORS). This CORS error is the default and both the client and server have to explicitly state 'no-cors' in their HTTP/HTTPS headers. When you disable CORS from the client request, you've found it doesn't work either. To me, this is more headache than it's worth even when you control all the code, because CORS pops-up when you think you've solved it For that last time! in an OPTIONS packet you didn't explicitly send (i.e., like a WS/WSS upgrade packet).

Answer: Because, like you I was frustrated for many hours with CORS, I've shown two solutions to the same problem and not explained it very well. 1) The reverse-proxy makes it to where A and B are the same origin and your B-Client can talk to A and A doesn't know the difference. 2) If you cannot do this, you can relay the REST call from your server. For example: B-Client sends a REST call to B, then B sends a REST call to A, A responds to B, then B responds back to B-Client. This works because the CORs checks are enforced by the client browser, and the server side just says which origins are allowed (kind of stupid if you ask me, and you can test this using a API design tool like Postman or Insomnia). I just tested both Nginx and Server-side REST relay independently in my code to make sure I'm not blowing smoke, and I'm not.

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?

When you say same location, what specifically are your referring to: IP-Address, domain name, sub-domain, etc?

@DDD said in How to check the "real-time" current of a extruder:

Trinamic drivers monitor that current

They monitor it only for the purposes of achieving the current you set and watching for short circuits. They don't provide feedback on the current achieved, apart from reporting short circuits.

@chrishamm @Falcounet Will OP's original ask be implemented in DSF-Python? We are not only interested in updated global variables directly, but other values within the ObjectModel as well. While a bit dangerous, allowing a way to directly interact with the ObjectModel could be extremely powerful.

@dc42 I'll keep an eye on it and try my best not to definitely fry my board this time

Really happy with how you design this board. It has been a blast playing with them.

Kudos to you and the Duet team!

You are controlling the laser as if it is a fan (which is not the best way to do it). The M106 L parameter sets the minimum allowed PWM.

It's fixed. Got another set of RJ11 connectors from a different vendor and everything worked out. Maybe those were defective. Old RJ11 connectors run out after a few tests, so comparing them against new ones is not possible.

I was using a generic RJ11 crimping tool with a generic RJ11 source from a local electronics shop.

It is worth mentioning that one time I over crimped the connector. There was conductivity from the 1LC to RJ11 but not from 1LC connected to the CAN connector on the mainboard.

@DDD said in Custom Splash Screen:

that's the info on the board

as in silk screen or also the marking on the cpu? does bossa agree as well?

Can't add much to the discussion as haven't played with tool changing, but I love how this project uses machine vision to calculate tool offset: https://hackaday.io/project/26053-tool-switching-multi-extrusion

Ian

I'll take a look.

Thanks for the fast answers.

I've been working with Marlin and Smoothieware, but the Duet it's a superior solution to anything I have seen. Congrats and keep up with the excellent work.

While posting on cold meds it's a bad idea, the G92 command did the trick. Thank you fellow Duet riders!

They are in mm. Decide where you want X=0 Y=0 to be relative to the proximal joint, and put those offsets in the X and Y parameters of your M669 command. The +X direction is the direction that the proximal arm points towards when it is at zero degrees angle.