-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Jog cancellation (0x85) sometimes not working #95
Comments
@luben111 : I'll look into this when I get the time, but first could you verify that Grbl is receiving the 0x85 command when you notice it fails? Not exactly sure what would be easiest way to do this. Maybe edit the serial RX ISR code to toggle a pin whenever it reads a 0x85. |
Good point, I'll check this |
@luben111 : you have mentioned that you are using labview would you like to share your work with me so i will be able to help/verify more/new features of grbl basically i am porting grbl to xmega avr where i am aimed to add G33 (tapping /threading ) g-code support and i need labview type application to test function integrity |
@shamsiqbal |
@luben111 i have retrofitted beaver vc5 cnc milling machine it was a mix of xmega and arduino nano but next version i am going to use only xmega128a1u |
@shamsiqbal Porting to XMega128 sounds like a good idea (despite that very soon will be available port to ARM), do you have some PCB for it? About jogging - the new GRBL v.1.1 has built in jogging control and I can say that it works really well - with the PC keyboard I can get technically the same behaviour as if using a pendant . |
@luben111 about xmega pcb i have built breakout board using photosensitive film method you can build one using toner transfer method its a simple smd to dip breakout board once i am done with porting i will build complete pcb using my own built cnc milling machine you can email me files on shams@bosonelec.com i am using v1.0 not v1.1 for grbl port because i have found some issues in v1.1 where my newly added parameters wont get saved properly
i think its not important to port grbl on ARM but to go for S-curve motion planing . you have chosen lpc17xx arm port but it will be good choice if you had chosen stm32 nucleo board due economical price and on board debugging option available on it plz have look on stm32 nucloe boards available from st. cortex m3 vs cortex m4 and fpu is big difference i have 3k kintes mkv3 series cortex m4 mcu's in my stock but i still prefer stm32f4 family where standalone grbl based cnc controller is possible on stm32f429i discovery board in my opinion i will suggest you to plz consider stm32 family boards for grbl arm port |
@shamsiqbal : Before you go and start saying things that you have no clue about, please try reading the other issues threads. In particular, the thread about moving on to ARM. There is a lengthy conversation there about this topic. Also the LPC port was done by a user and is not my primary choice, as you'll see if had you read the topic. And for everyone that is demanding to use this ARM chip or that ARM chip or even FPGA, I'm done talking about this. It's getting ridiculous. |
@shamsiqbal : my brother and I ported grbl to the lpc17xx because there's a very large number of CNC boards sold which use it, but running a different firmware. As far as I know, grbl-lpc has faster step rates and block rates than any other grbl port. Will M4 perform better? Maybe. We'll see when you or someone else port to it. |
@chamnit : further these are your comments on https://github.com/gnea/grbl-Mega/issues/17 thread in this thread i have pointed three things i have been reading grbl code since v0.8 i have less experience on grbl then you have and if i am not able to perform any additional function its obvious thing to ask help from experts its not how things works but its all about code compatibility with existing function in grbl @tbfleming 👍 |
Please stop contradicting yourself. You stated this in your last post.
Please understand that answering questions on these issues threads takes time and energy. It's for determining if there are bugs or discussing important issues. What is not for is teaching every random person how to code for Grbl. The code is well-commented for this reason. Nor does it make any sense to try to help you on an older version of Grbl, when everything is moving forward with v1.1. What you want would be a complete waste of time for myself and others here. Also, all of the improvements you have suggested has been previously discussed in numerous locations and are already planned. Please try using Google and do some homework before posting here. It'll save everyone the precious time that they volunteer to help out. Time that should be spent on development or making something. |
ClearPath servos. |
Also, steppers on current-generation hobby lasers run close to 100 kHz. Future hobby lasers may need higher rates. |
@luben111 : Thanks for digging into this. It's possible there may be some bug in the state machine. I didn't vet it as much as I have in the past prior to releasing v1.1. But, first:
I suppose the question would be, what is the situation that you are sending a jog cancel and then still are sending jog commands? Does Grbl operate ok if you stop sending jog commands until it stops and then resume streaming jog commands? If so, perhaps I need to add a |
@chamnit
The situation is very simple and this is how my implementation of jogging is working on LabView:
Maybe adding [Jog End] message will not improve things because now we have to hang around the serial to see if it's accepting or not the 0x85 commands and if not to resend it. The best approach is if we can locate where this happen and to fix the logic. |
|
If this was the way how the jog cancellation was designed I can make a patch and delay the 0x85 command to the GRBL so it will take effect. Another option is to send it several times by hoping that one of the commands will come in the right time.
|
|
yes, this is the best approach - keeping some misbehaviour in the code and explaining to everybody how it should be avoided is not great. There is something else - very often behind a bug stays some other problem which is invisible. BTW, the GRBL code is really a masterpiece, I really appreciate all your efforts to support such sophisticated and well working engine. |
I have a similar problem but then I am trying to execute jogging by calling code directly, not via serial comm, so I am possibly on very thin ice. IMO the problem could be related to the EXEC_MOTION_CANCEL flag beeing reset before the cancel is completed, if a new cancel command is received before completion it will set EXEC_MOTION_CANCEL flag again and thus possibly cause all kinds of problems later? I am going to try to avoid this problem by not allowing the EXEC_MOTION_CANCEL flag to be set until the cancel is completed, not sure if this could work:
If not I will have to dig deeper... |
@terjeio The movement cancellation is actually working - whenever you send jog cancellation it will always stop the head. What is not working is purging the buffers of new incoming jog commands. So the scenario when you'll get jog misbehaviour is when you send the following sequence in short time:
In my case instead of sending multiple small segment jog movements I'm sending single jog command targeting the end of the working area (left, right, top or bottom). When doing horizontal and vertical movement simultaneously (pressed for example left plus bottom arrows of keyboard) and when releasing both buttons almost simultaneously the described above sequence may occur. For example if moving left + up and releasing buttons I may get the following picture:
|
@luben111 : "purging the buffers" is the clue, since jog cancellation is picked off the input stream in real time the jog command to be cancelled may still (partly) be in the serial input buffer? I''ll check what happens if I flush the buffer on a jog cancel but I suspect it will not be a 100% foolproof solution. |
@luben111 : Thinking about this some more before I commence testing: flushing the serial buffer, inserting a CAN (ctrl-X) into the buffer and use that to flush the line buffer in protocol.c may be even better. |
@luben111 : my solution above seem to work, I think you should try it. There may be a edge case related to the time window from the job command is queued for execution to sys.state = STATE_JOG; is set (in jog.c), if the cancel arrives in that window it will be missed. This is what I did: protocol.c
serial.c
added (NB! ARM code in my port)
Disclaimer: I am still trying to get to grips with the innards of Grbl so bear over with me if I am messing things up. |
@terjeio - where are these vars: I can't get them in GRBL 1.1 for Arduino UNO |
@terjeio |
For the original code I guess it would be something like this:
Adding your code above does nothing, you need to have the serial_cancel_read_buffer in place also. Edit: for clarity... |
@terjeio The main challenge is that we need to cancel the current movement but we can't just stop the head, it will take some time to complete the task and during this time window something bad can happen. It's something about buffers / queues. |
Ok fellas. I've had a bit of time to review what you have been up to and looked at the source code to isolate the issue. Based on @luben111's descriptions, this is my evaluation:
To me, this is still a non-issue, if the GUI implements the jog cancel as intended. If you cease sending jogging commands after sending a jog cancel 0x84 command and only resume once the jog cancel is complete, then there is no problem. To me, the matter is the GUI knowing when the jog cancel is complete. And as I stated before, Grbl can issue a quick message, like |
@chamnit |
@chamnit
|
@luben111 : There is an old trick that I forgot about to know when something is in sync. If you send a |
@chamnit Thanks - it's very useful ! |
Closing this issue as it seems to be resolved. @luben111 feel free to open a new issue if you run into problems with the proposed solution. |
Hi all, same problem here. I send:
But jogging continue even after sending Jog Cancel immediate command. |
I think this is what jog cancel command will do
I also observed no matter how many jog commands are there in the rx buffer after jog cancel, only one gets through planner buffer |
My work arround is, dont fill the planner buffer completly. If it is filled then jog commands will get queued in rx buffer which can not be cleared with jog cancel. In my app i do like if(PlannerBuffer > 5) then only send jog command. Even with this approch i still gets this problem, but that is very very rare |
This is what I am doing with button:
|
I am not sure to have real time and affordable knowledge of planner buffer. However I get a try |
Ya they can be disabled, in my app i check for that and re enables it. You can use G4P0 to sync the buffer after each jog command, this will also solves the problem. |
Thanks for the hint, it works. |
Its trail and error method, I updates the status report for every 150ms, based on that i found 5 is most suited value. |
I have also tried to remove sending of 0x85 directly from MouseButtonUp (that could happen at any time with some command unprocessed in grbl rx buffer) and moves it to rx thread. In MouseButtonUp I "schedule" jog cancel by setting a variable. In the rx thread I send the 0x85 only when I know that no pending commands (all previously sent command have received the ok/error response). This is same test I do to decide to enqueue a new jog command when I want to continue jog. This works too (seem add a little delay) but neither this solution or checking PlannerBuffer does satisfies my aesthetic sense :-) Sending a single jog command to the point which is the end of the working area as suggested by @luben111 seems to be the better way to do that, and since I don't need to runtime change the speed (not a joystick) the more effective. I'll do some test in this direction too. |
Waiting for "Ok" before sending any new jog command does not prevent the error. Grbl sends ok as soon as it get the jog command. If you are waiting for ok before sending any new jog commands, then you may not have a pending jog commands at your end but grbl still may have few commands left in its RX buffer. It may or may not even finished its first jog command. Delaying the jog cancel could be danger (may be not for laser mills), as machine will not stop at the expected location. |
How to you guys send 0x85 to grbl, i mean what it the command line for that ? i'm interfacing esp32 between arduino uno and grbl sender using bluetooth serial com, everything is working just fine (even sending job file is perfect) and i wana add jog button to my controller box by programing the esp32 to listen to the pushed buttons and send to arduino the jog commands, all is good but can'nt stop the jog when i release the button because i don'nt know the right command for that. |
I haven't really used Arduino but I'd expect something like Serial.write(0x85) |
Thank you langwadt, i finaly figured out some different aproach without using cancel command and here is my code put into ESP32 to send jog commands to arduino uno and it turns working just fine: #if !defined(CONFIG_BT_ENABLED) || !defined(CONFIG_BLUEDROID_ENABLED) BluetoothSerial SerialBT; uint8_t serialValue = 0; // Buttons pins setup void setup() { // Serial and BT setup // Buttons pins mode setup void loop() { // BT <-> COM data flow // Joging // Reading which button has been pressed and take its axis move // Moving according to the pressed button
} else { // Lets put some latency to remove button electrical noise } ` |
I dont know why some lines of code look different shape but they are all one piece. |
Hi,
I'm using LabView to control GRBL v1.1 (downloaded the latest GRBL few days ago). Everything works like charm except that I spotted something which might be a glitch in the jog control. The bug is that sending 0x85 to the GRBL sometimes is not aborting the movement. Let me explain in details the circumstances when this occurs. I recorded all data sent to the COM port (char <…> is the 0x85) when the problem occurred :
G00 X-0.30 (1)
$J=G90X-558F2000 (2)
…$J=G90X-558Y-2F2000 (3)
…$J=G90X-558F2000 (4)
… (5)
X+ was just pressed, send single step movement to absolute position
If X+ jog key pressed for longer than 500ms the program sends jog command and instead of sending frequently jog steps I'm targeting the end of the area (x= -558). At this point the machine begins to move smoothly to the end of X axis (-558).
While moving in X direction I can also press the Y- jog key , 0x85 was sent before the command to abort the current jogging movements. This works well, now the head moves simultaneously to end of X and to the beginning of Y axis.
Y- key released , send 0x85 to abort current jogging and send new jog commad targeting end of X axis (x=-558)
the X+ jog key released - sending 0x85 to abort the jog operations. The problem appears exactly here - in 2-5% of the cases the machine just ignores 0x85 command and continues to move.
Let me know if you find something incorrect in my jog commands which may cause the problem.
In short - sometimes 0x85 command is not aborting the currently executed jog movements.
Best regards,
Luben
The text was updated successfully, but these errors were encountered: