Ability to store and process data?

o_lampe

@heki You can poll any available data from the object model and store it on SD-card. (not sure about accelerometer data)
Processing or plotting will happen on the PanelDue or DWC.

chrishamm

@heki It sounds like you need real-time control, so you'd probably have to change the firmware to achieve that. RRF already supports data collection of accelerometers (see M955 and M956) but the received data is only written to CSV files and not (yet) exposed via the object model.

T3P3Tony

@heki is this data collection phase supposed to occure during a set of tests moves or during every print?

The quickest way to do this would be to connect the accelerometer to an SBC (Raspberry PI) connected to the Duet in SBC mode and then write a script on the pi that grabbed the accelerometer data, the position from the Duet, and then stored it. The control commands could also be sent from this script, or they could be generated in advance.

heki

@t3p3tony Thank you so much for your reply. So actually we've considered using RPi but the thing is that our motion command data and accelerometer data will need be able to be aligned so that some input/output relationship can be computed (and yes, this data collection only occurs during a set of test moves, not for every print). Using RPi to do this, it may be a little bit hard because there is no absolute timestamps on the data/command to align.. or is there?

The ideal case would be if the input collection and processing can be done on the board, at same sampling frequency, so that this aligning process is smooth. But if not, do you think there's another way to align this using RPI?

T3P3Tony

@heki how precisely co-ordinated do you need the correlation?

heki

@chrishamm Thank you so much for the reply. So to be precise, it needs the "sending command" and 'receiving data" tasks to be aligned, so that some input/output relationship of the printer dynamics can be computed (either in real time, or after some time delay). So do you mean it will be hard to do both "sending" and "receiving" in the board to compute, since the received data may not be exposed via object model, so it needs some conversion post-processing to do computation on the data afterwards?

heki

@t3p3tony So the timeframe onto which the input/output should be aligned is in 1 ms units, but at this moment I've yet to test how sensitive the input/output relationship will be by changing the precision of alignment..

heki

@o_lampe I see, thank you so much.

o_lampe

@heki said in Ability to store and process data?:

So do you mean it will be hard to do both "sending" and "receiving" in the board to compute, since the received data may not be exposed via object model,

I wouldn't connect the accelerometer to the Duet, but let the RasPi read out the data directly. There are Arduino libraries for the accel-sensor, they can be rewritten in python, for sure.

BTW: the sample rate of the sensor is pretty low (some kHz?) . I'd rather use interrupts to control the poll-rate instead of fixed intervalls.
That optimizes the amount of processable data.

T3P3Tony

@heki so in rough outline the data flow is:

read from input (SD card, USB, Network, UART etc)
process (buffer, plan, step generation)
step output to motors

The difference in SBC mode for commands coming from the SBC is the input stage can be intercepted and logged/used in some way. Other than that the Duet is doing the processing and step generation.

What exactly do you need to collect?

Whole moves?
individual steps?
something in between?

You may be able to get what you need but running a move, capturing the accelerometer data as we do already and then processing it after the fact. then running another move. After all you know the move you commanded, and you know the accelerometer response.