Intro + absolute coordinates + jog/DRO ideas

[Dean Gouramanis]

Hello BeagleG community. My name is Dean. I am building a miniature CNC milling machine. It has been a 4 year project. I have been working with BeagleG since March 2017.

The machine is functional right now (although incomplete).
https://youtu.be/YpW9kkOM5Ro

Today I am trying to use the machine to fabricate the "switch panel plate". Here is a picture of the CAD model.

https://www.instagram.com/p/BSrb6BFhA_k

There are six G-code programs total for the part. The programs are separate because I need to switch drill bits manually.

For the first program I set zero using G92 G90. In the second program I use G90, but looks like BeagleG has defined a new zero position. Is there a way for BeagleG to remember the software "zero absolute" between programs?

Is there a variable I can access which holds the current software coordinates? Has anyone worked on DRO functionality?


I plan to work on Jog/DRO functionality for BeagleG. (For now the joystick and switches are just for show!)

I have already designed some #OpenHardware which polls all the switches/joystick, and communicates over UART to BBB. The circuit also handles emergency stop.

https://github.com/dgouramanis/OPTOCAPE/

At the moment my plan is to continuously monitor the Jog hardware with a daemon. The daemon could rapidly generate/execute short G-code files from a shell script to jog the machine. This may be a bit jerky and error-prone. Just brainstorming at this point.

[Henner Zeller]

On 26 April 2017 at 02:11, Dean Gouramanis <temprod...@gmail.com> wrote:
> Hello BeagleG community. My name is Dean. I am building a miniature CNC
> milling machine. It has been a 4 year project. I have been working with
> BeagleG since March 2017.
>
> The machine is functional right now (although incomplete).
> https://youtu.be/YpW9kkOM5Ro
>
> Today I am trying to use the machine to fabricate the "switch panel plate".
> Here is a picture of the CAD model.
>
> https://www.instagram.com/p/BSrb6BFhA_k
>
> There are six G-code programs total for the part. The programs are separate
> because I need to switch drill bits manually.
>
> For the first program I set zero using G92 G90. In the second program I use
> G90, but looks like BeagleG has defined a new zero position. Is there a way
> for BeagleG to remember the software "zero absolute" between programs?

Can you describe more what you need, e.g. What are the GCodes you send
and what is what you expect it to do but what it does instead ?
BeagleG tries to be pretty standard conformant w.r.t. the coordinate
system manipulation, but that doesn't mean that is is not doing it
wrong.

> Is there a variable I can access which holds the current software
> coordinates?

The coordinate system values for G54 and up are stored in the
'standard' parameters #5220 and up. You can access them in gcode
wherever a number is expected.

I think storing the offset for G92 in #5211 and up is not implemented
yet, but that should be quick.

> Has anyone worked on DRO functionality?

Leonardo has worked on exposing the current position to some readout
that is working independently of GCode M114, that also takes the
actual current position into consideration (not what is enqueued to
the motors, but also the current step the motor is in). Not all of
that code is yet back merged into BeagleG.

>
> I plan to work on Jog/DRO functionality for BeagleG. (For now the joystick
> and switches are just for show!)

I have an old hack that reads a joystick and emits GCode
https://github.com/hzeller/joystick-gcode-jog

.. but this just emits GCode and guesses how fast the machine is
going. It would be good if we can directly control within BeagleG.

>
> I have already designed some #OpenHardware which polls all the
> switches/joystick, and communicates over UART to BBB. The circuit also
> handles emergency stop.
>
> https://github.com/dgouramanis/OPTOCAPE/
>
> At the moment my plan is to continuously monitor the Jog hardware with a
> daemon. The daemon could rapidly generate/execute short G-code files from a
> shell script to jog the machine. This may be a bit jerky and error-prone.
> Just brainstorming at this point.

Have a look at my joystick-gcode-jog example above as a starting
point. It is not perfect, as you predicted, it can create some jerkey
motion.

-h

[Leonardo Romor]

Hello!

Il giorno mercoledì 26 aprile 2017 11:11:48 UTC+2, Dean Gouramanis ha scritto:

Hello BeagleG community. My name is Dean. I am building a miniature CNC milling machine. It has been a 4 year project. I have been working with BeagleG since March 2017.

The machine is functional right now (although incomplete).
https://youtu.be/YpW9kkOM5Ro

Today I am trying to use the machine to fabricate the "switch panel plate". Here is a picture of the CAD model.

https://www.instagram.com/p/BSrb6BFhA_k

There are six G-code programs total for the part. The programs are separate because I need to switch drill bits manually.

For the first program I set zero using G92 G90. In the second program I use G90, but looks like BeagleG has defined a new zero position. Is there a way for BeagleG to remember the software "zero absolute" between programs?

Is there a variable I can access which holds the current software coordinates? Has anyone worked on DRO functionality?

The DRO functionality should be almost finished it just need to be connected upstream.
We were thinking of returning the current position through a gRPC server in order to both stream positions/auxes status and one day even send commands

such as pause/resume stop etc.. 

 

I plan to work on Jog/DRO functionality for BeagleG. (For now the joystick and switches are just for show!)
 

I have already designed some #OpenHardware which polls all the switches/joystick, and communicates over UART to BBB. The circuit also handles emergency stop.

https://github.com/dgouramanis/OPTOCAPE/

At the moment my plan is to continuously monitor the Jog hardware with a daemon. The daemon could rapidly generate/execute short G-code files from a shell script to jog the machine. This may be a bit jerky and error-prone. Just brainstorming at this point.

For the jog we started talking about a "speed-controlled-mode" such that the PRU  instead of crunching motion segments will behave more like a frequency generator.

- Leo

[Dean Gouramanis]

What are the GCodes you send and what is what you expect it to do but what it does instead ?
BeagleG tries to be pretty standard conformant w.r.t. the coordinate
system manipulation, but that doesn't mean that is is not doing it
wrong.

Program 1:

G70 ;inches
G92 ;set Zero
G90 ;coordinates absolute

G0 X2.0000

Program 2:

G70 ;inches
G90 ;coordinates absolute

G0 X1.0000

I expected Program2 to move the machine 1 inch in the negative direction. Instead it moves 1 inch in the positive direction. Making the final position X3.0000 as defined by G92 in the first program.

The coordinate system values for  G54 and up are stored in the
'standard' parameters #5220 and up. You can access them in gcode
wherever a number is expected.

I think storing the offset for G92 in #5211 and up is not implemented
yet, but that should be quick.

I noticed G10, and G54 in the readme. On other machines I was able to use G92 for jobs with one origin. Perhaps I need to use G10/G54 to restore the origin data in Program2?

I started drilling yesterday with no encoders or limit switches. So I cant test anything right now, or ill lose the position.

I have an old hack that reads a joystick and emits GCode
https://github.com/hzeller/joystick-gcode-jog

.. but this just emits GCode and guesses how fast the machine is
going. It would be good if we can directly control within BeagleG.

Wow. Nice work. I forgot BeagleG can stream commands from a TCP port. That's much faster than what I had in mind.
 

Have a look at my joystick-gcode-jog example above as a starting
point. It is not perfect, as you predicted, it can create some jerkey
motion.

I imagine it's tough to get around the jerkeyness since step gen is done in the PRU.

Looking forward to getting started on this. Probably next month.

[Dean Gouramanis]

Hi Leo.
 

The DRO functionality should be almost finished it just need to be connected upstream.
We were thinking of returning the current position through a gRPC server in order to both stream positions/auxes status and one day even send commands

such as pause/resume stop etc..

That's very exciting news.

I'm not fully up to speed on BeagleG yet, but I am under the impression the PRU is essentially programmed as a G-code interpreter. In that case it would be important to minimize extraneous processes in the PRU.

Never heard of gRPC until now. Looks straight forward. I like C languages. I do have experience coding 8-bit MCU as a motion controller, for which I devised my own protocols. They are all light-weight as possible, because step generation and positional integrity need to be the priority.
 

For the jog we started talking about a "speed-controlled-mode" such that the PRU  instead of crunching motion segments will behave more like a frequency generator.

That would be pro. Awesome.