Hi guys,

thanks again for your ideas and tips. It's been a while now, but I implemented and tested many ideas. In the meantime, I finished my toolchanger conversion and can finally perform proper tests.

I have tested the following:

1) An accelerometer mounted on the Tool-Carrier
@rjenkinsgb said in Direction/Velocity Vector of Printhead movement:

Could you use an accelerometer on the tool?
That would give instantaneous direction & acceleration ( so indirectly, velocity).

The idea is great, but after a few tests I unfortunately noticed that any vibration (door slam) affects my LED control. I know I could further process the sensor data through the Raspberry Pi and could solve the problem. But I don't like the fact that unplanned environmental influences can affect my control.

@t3p3tony said in Direction/Velocity Vector of Printhead movement:

@rjenkinsgb as it stands the accelerometer data is saved to a file during capture, not directly accessible through the object model.

I solved this problem by connecting the accelorometer directly to the Raspberry Pi.

2) Stay ahead of the movement with a code logger

@o_lampe said in Direction/Velocity Vector of Printhead movement:

IMHO to get ahead of the queue, you need to simulate gcode in real time on the Pi and send data to Duet simultaneously

@o_lampe has brought me to the idea, to analyze the queue with a code logger, make my calculations and keep them in a kind of buffer until I reach the current position. For this I wrote a script using the dsf-pyhthon API, which stores the commands that are sent to the RRF (State: Executed) and compares them with the current position.

The problems I have with this concept ist that I lose my reference when changing between absolute and relative positioning. Here I would have to program a parser that reads G90/G91 commands in addition to the G0/G1 and store the future absolute Position, as it probably is implemented in the RRF. This makes the script sluggish and not real-time capable. Or maybe my programming skills are just too bad to implement something like that.

3) My current concept

@resam said in Direction/Velocity Vector of Printhead movement:

Concrete printer and knife follower have definitely been a topic here. Usually they get controlled with an extra axis which gets positional movement instructions from the slicer / gcode directly (instead of trying to calculate it on the fly). See https://forum.duet3d.com/topic/6993/requests-for-help-gcode-cam-follower-tangential-knife-control

Thanks to @resam for the forum post by @Russ-Gries. Following the discussions in this forum, I would like to proceed as follows:

• instead of trying to calculate the Position of the LED ring on the fly, i want the LED ring to be seen as an additional axis
• a post processing script should extend the positional arguments with another corrdinate (e.g. U) => alredy done
• Position U shall be recognized by a plugin (DSF Command Subscription around the OM) and control the LED Ring

My current problems are:

• if I don't configure U as an addition axis, G1 U10 commands are not parsed and not passed to the OM
• if I configure U as a kind of "virtual axis" the LED ring acts like a motor. This gives me delays caused by the path calculation, especially if I have multiple circular movements when the position changes from 360 to 0.

I am surprised that such a simple task (turn on LED in feed direction) becomes such a complicated project. Does anyone have an idea how I can configure a virtual axis but not "move" it as a real one? I have read about a second DDA ring, but haven't dived into it yet. Would that also be a possible solution?

@dc42 Thanks for the suggestion. A few other questions:

• Is there a referance how often the OM can be pulled (in a sec) without losing performance?
• Is there a way to force the RRF to parse an undefined axis and stream the values to OM? Or does that make absolutely no sense? For example to do something like that: G1 X10 Y10 U90 for LED Ring Position 90 deg relativ to the x axis.

I have already read these posts here and am still not sure which approach to take:

• https://forum.duet3d.com/topic/23659/stream-true-current-position/7?loggedin=true
• https://forum.duet3d.com/topic/26378/polling-the-position-of-the-printer?_=1643369305548

@CNCModeller: I think you mean something like this: https://www.mdpi.com/2504-4494/5/3/82?type=check_update&version=2

Hi guys,

thanks again for your ideas and tips. It's been a while now, but I implemented and tested many ideas. In the meantime, I finished my toolchanger conversion and can finally perform proper tests.

I have tested the following:

1) An accelerometer mounted on the Tool-Carrier
@rjenkinsgb said in Direction/Velocity Vector of Printhead movement:

Could you use an accelerometer on the tool?
That would give instantaneous direction & acceleration ( so indirectly, velocity).

The idea is great, but after a few tests I unfortunately noticed that any vibration (door slam) affects my LED control. I know I could further process the sensor data through the Raspberry Pi and could solve the problem. But I don't like the fact that unplanned environmental influences can affect my control.

@t3p3tony said in Direction/Velocity Vector of Printhead movement:

@rjenkinsgb as it stands the accelerometer data is saved to a file during capture, not directly accessible through the object model.

I solved this problem by connecting the accelorometer directly to the Raspberry Pi.

2) Stay ahead of the movement with a code logger

@o_lampe said in Direction/Velocity Vector of Printhead movement:

IMHO to get ahead of the queue, you need to simulate gcode in real time on the Pi and send data to Duet simultaneously

@o_lampe has brought me to the idea, to analyze the queue with a code logger, make my calculations and keep them in a kind of buffer until I reach the current position. For this I wrote a script using the dsf-pyhthon API, which stores the commands that are sent to the RRF (State: Executed) and compares them with the current position.

The problems I have with this concept ist that I lose my reference when changing between absolute and relative positioning. Here I would have to program a parser that reads G90/G91 commands in addition to the G0/G1 and store the future absolute Position, as it probably is implemented in the RRF. This makes the script sluggish and not real-time capable. Or maybe my programming skills are just too bad to implement something like that.

3) My current concept

@resam said in Direction/Velocity Vector of Printhead movement:

Concrete printer and knife follower have definitely been a topic here. Usually they get controlled with an extra axis which gets positional movement instructions from the slicer / gcode directly (instead of trying to calculate it on the fly). See https://forum.duet3d.com/topic/6993/requests-for-help-gcode-cam-follower-tangential-knife-control

Thanks to @resam for the forum post by @Russ-Gries. Following the discussions in this forum, I would like to proceed as follows:

• instead of trying to calculate the Position of the LED ring on the fly, i want the LED ring to be seen as an additional axis
• a post processing script should extend the positional arguments with another corrdinate (e.g. U) => alredy done
• Position U shall be recognized by a plugin (DSF Command Subscription around the OM) and control the LED Ring

My current problems are:

• if I don't configure U as an addition axis, G1 U10 commands are not parsed and not passed to the OM
• if I configure U as a kind of "virtual axis" the LED ring acts like a motor. This gives me delays caused by the path calculation, especially if I have multiple circular movements when the position changes from 360 to 0.

I am surprised that such a simple task (turn on LED in feed direction) becomes such a complicated project. Does anyone have an idea how I can configure a virtual axis but not "move" it as a real one? I have read about a second DDA ring, but haven't dived into it yet. Would that also be a possible solution?

@t3p3tony In the short term this could work, but in the long term it would be better to be able to read the queue directly to enable directional in-situ control. Is there an alternative to the OM? Does it make sense to reprogram the firmware? The topic is part of my master thesis and I have to consider all alternatives.

@t3p3tony: In the meantime I wrote myself a small script that reads out the positions from OM during the movements of the printhead.

The problem that comes up when I calculate the direction vector over the last point minus the current point is that the direction vector runs behind the current movement. To get the correct vector I need the point the print head is moving towards. (So a point in the future).

I did some more research on this and came across the following article from 2017: https://forum.duet3d.com/topic/2985/current-position
Here dc42 describes that the current position is updated only at the end of each movement. Is there meanwhile a way how I can output the next position, which the printhead moves to?

@t3p3tony: Thanks for the quick feedback. I thought about that, but I think it would be more efficient to get the information directly from the path planning of the controller. Is there a chance to do this? I want to output the control signals as quickly as possible, as a kind of "real-time" control.

Hello guys,

I have an application where I need control signals depending on the feed direction preferably in "real time". Currently I am using a simplified test setup consisting of a Duet3 Main Board 6HC in SBC mode with a Raspberry Pi 4 and a LED ring that I want to use for visualisation purposes of the control signals (PWM 0 to 5V).

I am new to the Duet software framework and am looking for a way to be able to read the feed direction from the printer controller. I have already looked at the DSF ObjectModel and discovered the ModelObject CurrentMove. However, all variables (speed, acceleration, deceleration, etc.) are only displayed as absolute values. To be able to make conclusions about the direction I need the information as a vector.

Can anyone tell me where I could get the information about a direction vector, or whether someone is planning something similar or has already implemented it? So far I have not been able to find anything comparable on the duet forum.

Alternatively, I would also have the idea of using an accelerometer. But first I would like to check the software implementation.