Queue status

[lromor]

Hello @hzeller , is it possible, from the actual state of the code, to get the queue status from an external process (for example monitoring)? If the code is not ready yet and if you are interested in this feature, how would you like it to be implemented?

[hzeller]

The queue status as in how many elements are enqueued is not yet monitored, but it can be determined relatively easily. Within on queue element (say the PRU is just doing a line - where it is exactly there) is as well not exported yet, but it could be changed with constantly exporting that state to a memory location (a step counter is sufficient, the rest can be deduced in the host program). The latter is needed not only for monitoring, but also to correctly re-start an interrupted operation.

Monitoring externally should be done via a socket, but I have not thought about the details of the protocol. I am currently attaching a screen to BeagleG and in the process think about what needs to be exported in what way.

[hzeller]

What are the parameters you want to monitor ? It is always good to have a use-case in mind before implementing something.

[lromor]

Well, the cases that come to my mind are for example to render in realtime the path of the machine or sync the movement with another operation (delegate the control of another tool to another process and an orchestrator that control both of them).

[lromor]

ok, So I will try to set a counter inside motor_interface_pru, mapping a u32 integer for each motor which increments/decrements each time it has done a step.

[hzeller]

No, you only need to expose the values of the registers exposing loops_accel, loops_travel and loops_decel. To simplify, the sum of these is sufficient. The rest can be calculated from there, as all motors are linearly dependent. So I suggest to push these after every step in some shared memory area, and think about how we can make that concurrent-access safe (I have some idea here, but I leave that as an exercise :) ).

Anyway, before you do that, you need to figure out which queue-element we are currently processing - the individual state within one command does not help when we don't know which command we execute. On the host side we need to know that command and its parameters to reconstruct where we are currently globally. There is an expensive way (just walk the queue until we find the first that is being processed), but also simpler ways (I have some idea for that, but let me know what your plan is here).

[lucalenardi]

Hello @everybody!

First of all thanks for all the great work done with BeagleG.

Recently I was wondering what would be the best design to share the information gathered from the PRU – about the actual queue status, indeed – with the external world.

So let's first define exactly what would be nice to share:

• current G-code instruction, in the instructions list;
• number of steps executed over total number of steps for the current instruction (summing up all the motion-segments needed for that instruction), and or;
• the exact axis position, in metric unit (i.e. X:0.00 Y:0.00 Z:0.00).

A couple of possibilities come to mind:

1. extending the existing TCP socket in machine-control, to stream the information to the client continuously, and let it parse the information whenever needed;
2. accept the appropiate GM-code instruction, evaluate it and return a response with the actual position of the axis (x, y, z) – see this M instruction for an example;
3. use a mmap file to share those information with other processes;
4. use some other sort of generic lib/tool to share information within processes, leveraging existing application, but introducing dependencies.

What would be your approach?

[bigguiness]

On Tuesday, March 29, 2016 8:30 AM, Henner Zeller wrote:

No, you only need to expose the values of the registers exposing loops_accel, loops_travel and loops_decel. The rest can be calculated from there, as all motors are linearly dependent.

So I suggest to push these after every step in some shared memory area, and think about how we can make that concurrent-access safe (I have some idea here, but I leave that as an exercise :) ).

Anyway, before you do that, you need to figure out which queue- element we are currently processing. And also keep track of that on the host side. There is an expensive way (just walk the queue until we find the first that is being processed), but also simpler ways.

I have some idea for that, but let me know what your plan is here.

Henner,

I have not put any thought into "what" data needs to be exposed, but I have an idea on how to return the data via another socket.

How about using a separate UDP socket? This would allow BeagleG to not rely on the socket always being connected. BeagleG can then occasionally poll the socket using a short timeout with select(). If a connection is detected it would then do a recvfrom() the socket to get a "command" to process. The commands need to be determined but they could be stuff like:

1) get position (actual and/or target) 2) start/resume motion 3) pause motion 4) jogging control 5) other?

The "server" side in BeagleG is pretty simple:

1) create a UDP socket 2) bind the socket 3) occasionally check for data using select() and recvfrom() 3a) process any received commands

The remote "client" side is also pretty straight forward:

1) create a UDP socket 2) bind the socket 3) send a command to BeagleG using sendto() 3a) receive the command response using recvfrom()

What do you think?

Hartley

[lromor]

Ok, So now we have the core functionality of update-status, Now we should wire up it to the actual gcode command as Henner pointed out.

In the wiring process are we going to remove the blocking wait for the PRU to free a slot? In this way we could avoid freezing beagleg when the queue is full.

Also, It should be time to decide whether or not we want the UDP server.

[hzeller]

Let's discuss this on the mailing list.