Future Option for Linear Absolute Encoders

PCR

@neueklasse said in Future Option for Linear Absolute Encoders:

Renishaw RTLA30

One Idea is to get the Position with a arduino or ESP. And the. Send a G92 with the exact Position ?;)

NeueKlasse

@pcr
The problem is you need to do it manually, that’s
not what i want.

roiki11

What you'd need is a pid controller on the duet, implementing the outer position loop. This isn't currently possible.

Also if you need it to maintain position across power cycles you need absolute encoders. Which are quite expensive.

NeueKlasse

@roiki11 the Renishaw Absolute Encoders are about 70€ for 150mm length... (different Communication Possibilities)

another way i thought is to Save the Actual Stepper Position with daemon.g and load it after each restart with runonce.g but i don't know in which variable i can save the Position?!

(maybe combine that with a Magnetic Stepper Brake to make sure the stepper doesn't move while off)

Any Thoughts?

roiki11

@neueklasse

If you get them used. New they are ~~300-500~~ 1k and over.

Also you have no way to interface absolute encoders to duet. No protocol support. And using incremental doesn't work as you have no way to actually know if the system has moved or not. So you need to home it to be sure.

Or just don't shut down the machine so you don't need to home it.

alankilian

@neueklasse said in Future Option for Linear Absolute Encoders:

For a Future Projekt i need to monitor the exact Position of an Axis, even after complete Powerdown of the Duet Board/System. ... how would this be possible?

I don't know if this will work since I don;t know anything about your requirements, but how about using an incremental rotary encoder on your stepper motors connected to a battery-backed Arduino or other embedded board that communicates with the Duet?

The Duet would send a message to the external board after homing the axes to let it know the current position.
The external board keeps track of the position of the steppers continuously.
When the power goes out, the external board CONTINUES to watch the encoder and calculate the position because it's got batteries that can power it for a few days.
When the system restarts, the Duet can ask the external board what the current position is and set that internally.

If something like this would work for you, we can start to work out more details.

JoergS5

@neueklasse said in Future Option for Linear Absolute Encoders:

Save the Actual Stepper Position with daemon.g and load it after eac

This will not work, because steppers change their positions after restart of the controller, up to +- 2 full steps, which is more than your 0.05 mm accuracy (with 20 teeth pulley, 200 stepper and GT2 belts it would be +- 0.4 mm). So to be sure you recover the correct position, the position must be read and stored before the stepper is activated. After stepper activation, the position is probably changed by the stepper and must be recovered by stepper position correction. Then the firmware can be told the stepper's (and axis) position.

NeueKlasse

@joergs5 the Steppers i use are Nema23, with a 11x2 Spindle, i trust them to be accurate enough to handle that (to be clear it’s a Z and U Axis.. height adjustment)
due to the Spindle pitch it‘s self retaining…

JoergS5

@neueklasse said in Future Option for Linear Absolute Encoders:

Nema23, with a 11x2 Spindle

Steppers +- 2 fullsteps are then +- 0.02 mm, which is inside your range, you're right. Detent Torque of a Nema 23 is also quite high, so the Z axis should not move down when powered off.

About Renishaw, to use it you should check how to use the supported protocols, as they are all (or most of) protocols for specific commercial products. I thought of an alternative AMT21/23..., part of them are absolute encoders, they use standard protocols/interfaces/bus like RS485, but they need battery buffers to store the absolute position, I suspect. The accuracy is 0.2 degree, which means 1 micrometer for the spindle solution, when no gear is used.

The 1HCL will not help you imho in this case, as it reads differential quadrature signals for closed loop stepper implementations, but doesn't read absolute positions.

The hint above using Arduino, ESP32 or alike was imho a good one to install it between the encoder and the Duet. You should check whether there are libraries to support one of the Renishaw protocols (Biss C, DRIVE-CLiQ, FANUC, Mitsubishi, Panasonic, Yaskawa).

o_lampe

I'd look for an ESP to buffer the position, because it wouldn't need level shifters and it has power saving features like wake up on interupt

NeueKlasse

@joergs5 How to tell the Duet, (Duet3 btw) the actual Position from the ESP Board?
then it would be interesting,
i checked the Information about the HCL Board.. it's simply just a "Standard" for the most common Encodertype that's in Use in the Printers, so for me sadly no way.

now i test a little bit around with Variables and Assignments...

i created these 2 in the config.g file:

; Variables
global LastZAxisPosition = 0
global LastUAxisPosition = 0

in other Controllers (example ABB, KUKA) they will be updated in the config file if i set an Value,
in the Duet Framework after a Restart it's 0 again (like i wrote the in the config file...)

JoergS5

@neueklasse said in Future Option for Linear Absolute Encoders:

How to tell the Duet, (Duet3 btw) the actual Position from the ESP Board?

Duet has a very clever concept: it is controlled by G-Code commands completely. Everything from config.g to sliced 3D printing is based on it. So the ESP32 needs to send a G-Code command like a G92 to the Duet, that's it. You only need a connection between ESP and Duet which is supported by both. ESP and Duet support eg SPI, I2C, http, even TCP through WLAN if Duet supports Wifi. If Duet 3 is in the internal network, the ESP32 could send the data through WLAN and router to the Duet 3.

NeueKlasse

@joergs5, @PCR i think i like that way, i order an ESP to test it out!

JoergS5

@neueklasse said in Future Option for Linear Absolute Encoders:

work after a Restart it's 0 again (like i wrote the in the config fil

there was a thread recently how to store global variables:
https://forum.duet3d.com/topic/24880/does-rrf-have-maintenance-counters-timers

NeueKlasse

@joergs5 i tested that,

=> config.g = global ZAxisPos = 0
=> i created a "VariableBuffer.g" file in the sys Folder and Inside:
set global ZAxisPos = 0

then A Macrofile w.

M28 "0:/sys/VariableBuffer.g"
set global.ZAxisPos = -25
M29

After Calling the Macro the Variable inside the VariableBuffer.g file is Updated,
it's also persistent through a Restart.

if i set it under the M29 Command in the Macro: G92 Z{global.ZAxisPos}
the Z Value Remains 0

so i checked it in the Objekt Model Browser under "global" ... it remains 0.

JoergS5

@neueklasse I did not use and test it myself, I only saw the thread. If you have negative results, you could post your try and question in this thread where storing the variable was discussed.

NeueKlasse

@joergs5

the easiest way i think would be over UART, but in my case a PanelDue is connected on IO0,
do i have to Activate the SPI Protocol (M576) to send the Commands via the GPIO Header and
the SPI Pins?
I think the Second UART Port on IO1 is not working right now?

JoergS5

@neueklasse you don't need something fast or permanent for this task, so I would not waste a dedicated line, but use the Lan connection.*)

*) but there is https://github.com/technik-gegg/SMuFF-Ifc which could be used to be between Duet and Paneldue. But I2C is sensitive, I would prefer Lan.

If I remember correctly, you're using a Raspi with Octoprint also, so using Lan for all communication would be fine and usable for other ideas.

A different direction would be CAN-FD, with a board like Teensy 4 or Sammy-C21, or using the MCP2542FD chips. The Duet 3 is a groving environment with CAN-FD components, enlarging it with a component for encoder would be interesting. But this may require some development of the communication.

dc42

@neueklasse I've been looking at whether the forthcoming closed loop board could support this type of absolute encoder. It appears to me that it could, with a little extra hardware (possibly on a daughter board) to provide an RS422 interface. We would use BISS C protocol to communicate with the encoder.

NeueKlasse

@dc42 Thanks for the info, that would be great! i'm looking forward to the developments.
BISS C would be perfect (at least in my Case)