grbl_6axis_on_stm32 icon indicating copy to clipboard operation
grbl_6axis_on_stm32 copied to clipboard

Seems unable to respond any command but '?' or '$$'

Open e-zeki opened this issue 4 years ago • 16 comments

Hello, Sorry to bother you with this. I was encountered the same problem you've mentioned here https://github.com/robomechs/6-AXIS-USBCNC-GRBL/issues/16 I was able to move or process some GCode but eventually it stucks along the way. I compiled your project as is, but first it didn't respond any of my homing, clear alarm, or any other movements commands. it responds '?' command for status, but thats all. What am I missing here? would you clearify for me or guide me through to the corect way. Thanks Zeki

e-zeki avatar Jan 03 '21 16:01 e-zeki

Did you check the step/mm parameter? Is your value not too high. Are you sure to use the right baudrate?

If you sent a Gcode command in order to move on e.g. 50 cm some axis and you specify a low feedrate (e.g. 100mm/min. So this movement should normally take some time. Then start sending "?" once every 10 sec. Does the status report show changing position and an "Run" status or are the position fixed and the status "Idle"

mstrens avatar Jan 03 '21 17:01 mstrens

I've got a setup for robomechs build and it was working just fine until I recognise some lines are missing out, then I realize the "ok" response started to come as "o", even I ask "?" around 5-10 seconds or by buttons. it is clearly what you've mentioned above issue, but I couldn't get it working with your project.

I've got the baudrate correct I receive welcoming message and status query, it starts with Alarm state but its unable to respond my homing command(no movement on motor at all) or "$X" so I'm unable to go further. Is yours and robomechs are pin compatible? or do I need to twig some files in order to start? my step/mm "$100-101-102=110mm/s, F: 1500 in Gcode file.

e-zeki avatar Jan 04 '21 05:01 e-zeki

The project let the user changes the way the pins are used. My project has some light deviations in the way the pins are used because it was easier for routing some wires. You can easily go back to robomechs setup if you change a few lines in the file cpu_map.h

Take also care of the way you build the end stops (normally open or normally close); This is also a grbl parameter to set up according your hardware. It is normal that GRBL comes in "Alarm" at power on. It is a safety feature to avoid running without a homing. As the GRBL message said it, you have to send an UNLOCK command to GRBL first. If you are unhappy with this safety feature, you can also remove it by changing a GRBL parameter. All this is explained in the official GRBL 1.1 version web site on github (in the wiki part)

mstrens avatar Jan 04 '21 09:01 mstrens

Thank you for the explanations. I'll cross check the cpu_map.h files then try it again and let you know the results. Best wishes.

e-zeki avatar Jan 04 '21 09:01 e-zeki

Hello again. I've compiled and managed to get it working your code. But still "o\r" occurs. Another weird issue is I get "Door" in my "?" response. error 2 (Bad number format) then errror 9 (G code locked on alarm or jog state) error. I've send the gcode line by line by hand its ok. when I set it automatic mode it gives "Door" warning Any particullar reason for this?

e-zeki avatar Jan 12 '21 19:01 e-zeki

Hello again. I've compiled and managed to get it working your code. But still "o\r" occurs. Another weird issue is I get "Door" in my "?" response. error 2 (Bad number format) then errror 9 (G code locked on alarm or jog state) error. I've send the gcode line by line by hand its ok. when I set it automatic mode it gives "Door" warning Any particullar reason for this?

I'm sorry to bother you again, But I would very much like your oppinion and help on this.

Door issue was my mistake sorry I fixed it i think 10 sec for a "?" request a bit much. GRBL states no more than 4 request per second. I set my step/mm 100, acceleration rates 100 and I requested "?" once in every second and started getting "o/r" responses again. I developed the code according to available buffer size from "?" response in order to avoid "ok" responses but grbl crashes after a while of processing the lines I feed. what should be the best course to proceed from here Thanks Zeki

e-zeki avatar Jan 13 '21 20:01 e-zeki

When I reported this issue, I noticed that I was using a high value for the step/mm AND for the feedrate. In such a case, the STM32 has to generate a lot of pulses per sec and each pulse is managed with an interrupt. The interrupts needed in order to generate the pulses for the drivers have probably priority on the interrupt requested to manage the communication. Can you try to reduce the feed rate? Perhaps you can also try to reduce again the steps/mm (reducing the number of micro-steps on your driver).

Do you test on a real machine connected to drivers/motors that could generates noise on some wires (e.g. the end switch) . If so, it could also that this noise generates some extra interrupts that take some time to handle and does not let the STM32 serve the UART interrupt.

Perhaps we would have to change the program in order to increase the priority given to the incoming UART interrupt compared to the other interrupts.

Is it possible to provide me your config (all grbl parameters) and a Gcode that generates always the error.

mstrens avatar Jan 13 '21 21:01 mstrens

Can you try the following: in file "main.c" there is currently NVIC_PriorityGroupConfig(NVIC_PriorityGroup_4); NVIC_InitStructure.NVIC_IRQChannel = USART1_IRQn;
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;

Change it to NVIC_PriorityGroupConfig(NVIC_PriorityGroup_1); NVIC_InitStructure.NVIC_IRQChannel = USART1_IRQn;
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 1;

Let me know if it solve the issue. This increases the priority given to communication regarding driving the pulses.

mstrens avatar Jan 13 '21 22:01 mstrens

Hello again after so long. I've tried to reduce everything my configs are now $100-101-102 =100 , $110-111-112=500, $110-111-112=500, $120-121-122=80,

I added the NVIC settings as you set above, What I observe is, if I dont ask "?" every command sends "ok\r\n" no matter how frequent it is. as soon as I ask even once "?" it starts sending "o\r\n"

e-zeki avatar Jan 23 '21 09:01 e-zeki

It is not 100% clear. You say : as soon as I ask even once "?" it starts sending "o\r\n" After you send once a "?", does it reply "o\r\n"

  • after each new command?

  • from time to time after some commands?

  • each time after sending new "?"

  • some time after some new "?"

  • do you get correct response to "?" (status and positions,...) Where do you capture the data flow? On PC or at STM32 (with a ftdi or similar)? Do you have a seelea digital analyser in order to capture the signal TX/RX. If so, please send me the capture.

Do you modified my code? I do really do not understand what happens because this code is used by many users and no one reported such an issue.

mstrens avatar Jan 23 '21 10:01 mstrens

after each "?" command I receive status and position and after that I should receive an "ok\r\n" in order to understand its done. I capture the signal with another stm32 board (F401) via UART. every commad I send I receive "ok\r\n" after actions done. For example I send "$X" -> I receive : [MSG: Caution Alarm Unlocked] second send-> I receive "ok\r\n" or I send "$100=100" I receive "okk\r\n" without any problem but when I start sending "?" (500-750 ms periodically) in order to track coordinates and buffer length I receive Status report correctly then I received a "o\r\n" it should be "ok\r\n" but it loses k and as you mentioned on the robomechs issue it delays a bit. I dont have a digital analyzer ready now. I'll find one and cactch the frame on the line and compare the difference. I know its weird. but this happens.

I didn't modify your code I only changed cpu_map and your suggestions only

e-zeki avatar Jan 25 '21 05:01 e-zeki

Please note that (as far I know) when you send "?", GRBL is supposed to reply only with status and position (and \r\n) but not with an OK. GRBL send ok\r\n only after other commands like G01,G02,...and $X or $$ etc...

Anyway, it is not normal to get "o\r\n"

Can you send me you complete grbl settings ($$ parameters and cpu.h and config.h file if different from those on my site)

mstrens avatar Jan 25 '21 08:01 mstrens

hello again. I found the problem it was very weird. I made a new pcb for my receiving side and it was same result. But I cleared the cubeIDE project and rebuild it again it started working. its now working fine. I have another question though. When I start sending GCodes GRBL receives the line and put it planner buffer to execute. but before execute it sends "ok" which is normal. Is there a way to see how many lines in the planner buffer? for example I have a 40 lines of GCode which is repetition of these 3 lines G1X-100F3000.0 G1Z100F3000.0 G1Y100F3000.0 G1X100F3000.0 G1Z-100F3000.0 G1Y-100F3000.0 G1X-100F3000.0 when I start sending grbl sends immidiate "ok" responses and planner fits 38 lines of this. My point is I cant keep track of the lines that is being executed at that point. I immidiately saw 38 line send and received and GRBL is executing those lines correctly. Question is is there a way to see the current command being executed in the planner buffer? or is there a command to do it?

e-zeki avatar Jan 30 '21 08:01 e-zeki

As far I know there is no way to know the command in the planner buffer. You can know the number of lines in some buffers with the "?" command but you have to ask that you want to get it in your setup. Here an extract of the GRBL doc: (from here https://github.com/gnea/grbl/wiki/Grbl-v1.1-Interface )

Buffer State:

Bf:15,128. The first value is the number of available blocks in the planner buffer and the second is number of available bytes in the serial RX buffer.

The usage of this data is generally for debugging an interface, but is known to be used to control some GUI-specific tasks. While this is disabled by default, GUIs should expect this data field to appear, but they may ignore it, if desired.

NOTE: The buffer state values changed from showing "in-use" blocks or bytes to "available". This change does not require the GUI knowing how many block/bytes Grbl has been compiled with.

This data field appears:

In every status report when enabled. It is disabled in the settings mask by default. This data field will not appear if:

It is disabled by the $ status report mask setting or disabled in the config.h file.

mstrens avatar Jan 30 '21 09:01 mstrens

Thank you. I found block_buffer_tail is giving the line number on planner buffer that being executed which is almost what I asked above. I'll put a counter there to count to the end and put this value in to ? see if it works. if it works this is a very usefull data for keeping track of where exactly is the machine in case of a power down or some sort of error causes to restart all the process.

e-zeki avatar Jan 30 '21 09:01 e-zeki

I found Line number count is available by enabling from config.h (details are here below Line number https://github.com/gnea/grbl/wiki/Grbl-v1.1-Interface) That's what I was looking for. Thank you so much for your help. its great now smoothly working.

e-zeki avatar Jan 30 '21 10:01 e-zeki