grbl question

[SergeS]

I am making some PC-side software to control XYZ machine over grbl firmware. Not a CNC related, for some other purpose. Do not have any grbl expirience as far as CNC expirtience, so my beginner's question...

I have no problem controlling movements within one COMport session, like:
1) open com-port;
2) move to x1 y1 z1 absolute point;
3) move to x2 y2 z2 absolute point;
4) move to x3 y3 z3 absolute point;
5) close com-port.

Seems like every time when you close com-port, grbl loose current position and when you open port next time, it thinks we are on position 0-0-0.

Is this possible to preserve current position when you close port and enforce grbl use it as starting position when you open port next time?

In other words, how to make movements like this:
1) open comport;
2) move to x1 y1 z1 absolute point;
3) close com-port;
4) open comport again;
5) move to x2 y2 z2 absolute point, considering we are already on point x1 y1 z1;
6) close com-port;

[ballscrewbob]

You could use the eeprom to read and write values.

However most CNC usage can also use homing switches to represent home position and then move to an offset as a provisional home.

Your program would need to do the eeprom write preferably before the port closes and read after a true HOME position to maintain some extra accuracy.

It does sound more like a programming issue and if you want we can move it to that section for better answers ?

[SergeS]

You could use the eeprom to read and write values.

However most CNC usage can also use homing switches to represent home position and then move to an offset as a provisional home.

Your program would need to do the eeprom write preferably before the port closes and read after a true HOME position to maintain some extra accuracy.

It does sound more like a programming issue and if you want we can move it to that section for better answers ?

I am writing PC-side software, which sends commands to grbl controller. What do you mean by "use the eeprom"?

[ballscrewbob]

Use the EEPROM on the UNO to store its last co-ordinates before the com port closes.

That way you will be able to read them again when you open the com port and use them as a reference point / offset from home etc.

[SergeS]

Use the EEPROM on the UNO to store its last co-ordinates before the com port closes.

That way you will be able to read them again when you open the com port and use them as a reference point / offset from home etc.

Are there any grbl command to store/restore position?

Once again - I am writing software on computer side, not a firmware for Arduino.
Or I misunderstand you?

[ballscrewbob]

There are G-code commands for home position and for offsets etc.
They are NOT grbl commands as grbl only interprets the g-code and processes it.

If you are writing your own software you need to

A> Understand grbl and what it does.
B> Understand g-code and what its functions are capable of.
C> Only when you understand A + B can you write your own software that uses grbl.

Have you been to the GRBL site and read what it is capable of ?

[SergeS]

ok, thank you for your help :-)

[zwieblum]

It's not the brightest Idea to start with a not-homed device in the first place.

[Robin2]

Seems like every time when you close com-port, grbl loose current position and when you open port next time, it thinks we are on position 0-0-0.

I suspect saving values in the Arduino's EEPROM would require a re-write of GRBL unless it already has that capability. I would advise against any re-writing.

The problem is that the PC causes the Arduino to reset when it OPENS the serial port. You need to prevent that.

The simplest solution is for the PC program to keep the serial connection open until it is completely finished with the Arduino.

If that's not practical my preferred solution depends on whether you can connect directly to the Rx and  Tx (and GND) connections of the Uno. If you can then use a USB-TTL cable to communicate with the Uno rather than the regular USB cable. As only Rx and Tx are connected it will not cause a reset.

Alternatively it may be possible to prevent the reset if you can disable your PS program from activating the DSR or DTS signal when it opens the serial port. I suggest you write a short Arduino program for testing - one that blinks an  LED a few times in setup() and then does nothing else. If the LED blinks you will know that the reset has been triggered.

There are other ways to prevent the reset, including cutting a trace on the Uno board. But the reset feature is an essential part of the normal Arduino process for uploading programs so I would be reluctant to make a permanent change.


...R

[groundFungus]

Why are you closing and re-opening the serial port?

[SergeS]

Why are you closing and re-opening the serial port?

I am planning to use that XYZ machine for another purpose (automated keypads testing), not for CNC.
So, I am planning to go to specific position, automatically press the key on keypad under test and make sure I've got expected response from keypad interface. Closing and re-opening port is actually only for simplicity and my convenience - in this case I do not need to keep port opened during checking response from keypad.

If it is possible to preserve position - I will do two separated independent programs, one to control movements and another one to check keypad response. If it is not possible - I have to integrate both functionalities in one program.

[SergeS]

I suspect saving values in the Arduino's EEPROM would require a re-write of GRBL unless it already has that capability. I would advise against any re-writing.

The problem is that the PC causes the Arduino to reset when it OPENS the serial port. You need to prevent that.

The simplest solution is for the PC program to keep the serial connection open until it is completely finished with the Arduino.

If that's not practical my preferred solution depends on whether you can connect directly to the Rx and  Tx (and GND) connections of the Uno. If you can then use a USB-TTL cable to communicate with the Uno rather than the regular USB cable. As only Rx and Tx are connected it will not cause a reset.

Alternatively it may be possible to prevent the reset if you can disable your PS program from activating the DSR or DTS signal when it opens the serial port. I suggest you write a short Arduino program for testing - one that blinks an  LED a few times in setup() and then does nothing else. If the LED blinks you will know that the reset has been triggered.

There are other ways to prevent the reset, including cutting a trace on the Uno board. But the reset feature is an essential part of the normal Arduino process for uploading programs so I would be reluctant to make a permanent change.

Yes, I agree with you, I do not want to modify grbl software.
Thank you so much for idea about DSR/DTS, will try.
If it will not work, I will keep comport open all the time, it is still option for me, see my explanation below on how I am planning to use it.

[wildbill]

I really can't see what your issue is with simply keeping the port open.

[SergeS]

It's not the brightest Idea to start with a not-homed device in the first place.

I did not say - not-homed.
I have installed home limit switches, homing is working perfectly, I will perform it once on the beginning.
I am just asking is it possible for grbl to not loose current position if you close and re-open com port.

Seems like it is not possible, unless playing with DTR/DSR signals.

[SergeS]

I really can't see what your issue is with simply keeping the port open.

Just checking for possible options.