Arduino Forum

Using Arduino => Motors, Mechanics, Power and CNC => Topic started by: SergeS on Sep 17, 2020, 04:53 am

Title: grbl question
Post by: SergeS on Sep 17, 2020, 04:53 am
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;

Title: Re: grbl question
Post by: ballscrewbob on Sep 17, 2020, 05:12 am
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 ?


Title: Re: grbl question
Post by: SergeS on Sep 17, 2020, 05:52 am
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"?
Title: Re: grbl question
Post by: ballscrewbob on Sep 17, 2020, 05:55 am
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.

Title: Re: grbl question
Post by: SergeS on Sep 17, 2020, 06:12 am
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?
Title: Re: grbl question
Post by: ballscrewbob on Sep 17, 2020, 06:18 am
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 ?

Title: Re: grbl question
Post by: SergeS on Sep 17, 2020, 06:22 am
ok, thank you for your help :-)
Title: Re: grbl question
Post by: zwieblum on Sep 17, 2020, 09:06 am
It's not the brightest Idea to start with a not-homed device in the first place.
Title: Re: grbl question
Post by: Robin2 on Sep 17, 2020, 10:00 am
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
Title: Re: grbl question
Post by: groundFungus on Sep 17, 2020, 12:48 pm
Why are you closing and re-opening the serial port?
Title: Re: grbl question
Post by: SergeS on Sep 17, 2020, 05:42 pm
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.
Title: Re: grbl question
Post by: SergeS on Sep 17, 2020, 05:47 pm
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.
Title: Re: grbl question
Post by: wildbill on Sep 17, 2020, 05:55 pm
I really can't see what your issue is with simply keeping the port open.
Title: Re: grbl question
Post by: SergeS on Sep 17, 2020, 06:04 pm
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.
Title: Re: grbl question
Post by: SergeS on Sep 17, 2020, 06:05 pm
I really can't see what your issue is with simply keeping the port open.
Just checking for possible options.
Title: Re: grbl question
Post by: zwieblum on Sep 17, 2020, 06:17 pm
You can modify the "M2" command in grbl code to write a position to eeprom. And change the main() function to read that values.
Title: Re: grbl question
Post by: SergeS on Sep 17, 2020, 10:33 pm
You can modify the "M2" command in grbl code to write a position to eeprom. And change the main() function to read that values.
I did not get your idea, can you please explain?

https://wiki.shapeoko.com/index.php/G-Code
--- 8< ---
M2   Program Pause and End   M02 was the original program-end code, now considered obsolete, but still supported for backward compatibility. See M30 below.
--- 8< ---
Title: Re: grbl question
Post by: zwieblum on Sep 17, 2020, 10:47 pm
Yes, that's the idea. You cannot write to the eeprom every second, it breaks realtime operation. so write to it at the end of program.
Title: Re: grbl question
Post by: wildbill on Sep 17, 2020, 10:51 pm
It's fairly common to invent your own G-codes. The piece of firmware that processes different G-code instructions is probably just a giant switch statement (mine is) and that means it's easy to add to. I had a bunch of fake codes I invented for getting debugging information. So you can just find the highest numbered M code and make sure your new one is (much) larger. Try M777 perhaps.

That code can store pos to EEPROM. M778 can read the pos from EEPROM and go there.

Or you could just leave the com port open of course  ;)
Title: Re: grbl question
Post by: SergeS on Sep 18, 2020, 03:28 am
Yes, that's the idea. You cannot write to the eeprom every second, it breaks realtime operation. so write to it at the end of program.
So, what is the idea?
Modify grbl by injecting saving position into the M2 command?

I would not modify grbl code, I would prefer rather to keep comport opened all the time.
Title: Re: grbl question
Post by: SergeS on Sep 18, 2020, 03:29 am
It's fairly common to invent your own G-codes. The piece of firmware that processes different G-code instructions is probably just a giant switch statement (mine is) and that means it's easy to add to. I had a bunch of fake codes I invented for getting debugging information. So you can just find the highest numbered M code and make sure your new one is (much) larger. Try M777 perhaps.

That code can store pos to EEPROM. M778 can read the pos from EEPROM and go there.

Or you could just leave the com port open of course  ;)
Got your point, thank you. But I would not modify grbl code...
Title: Re: grbl question
Post by: Robin2 on Sep 18, 2020, 10:03 am
I would prefer rather to keep comport opened all the time.
Have you considered using a USB-TTL cable as I suggested in Reply #8? Then it would not be necessary to keep the com port open.

...R
Title: Re: grbl question
Post by: SergeS on Sep 26, 2020, 11:48 pm
Have you considered using a USB-TTL cable as I suggested in Reply #8? Then it would not be necessary to keep the com port open.
Yes, I have considered, it seems like very good hardware solution. But I have it almost done with software solution - keep port always open. And between software and hardware solution I would prefer software :-).