search

terjeio / ioSender

A GCode Sender for Grbl and grblHAL written in C# (Windows only).
BSD 3-Clause "New" or "Revised" License
222 stars 66 forks source link

Unhandled Exception Occured #294

Closed dontfeelcold closed 1 year ago

dontfeelcold commented 1 year ago

I'm getting the error (first pic) but when I add an M1 (2nd pic, G-code line 5), I don't get the error.

Any ideas on how to solve this?

Error

No error

terjeio commented 1 year ago

I have tested with a STM32F756 board (telnet and websocket connection) and I am not able to replicate. I do not have a Teensy available at the moment, awaiting delivery of a new one, so cannot check that. Does the same happen with a USB and/or a websocket connection (assuming you are using telnet)?

phil-barrett commented 1 year ago

Is that on a Teensy? If you post the GCode, I will give it a try.

dontfeelcold commented 1 year ago

Yes, that's on a Teensy 4.1 with your V2.09 board. Here is the G-Code.

% G90 G94 G17 G49 G40 G80 G21 (2D CONTOUR2) G54 S10000 M03 M08 G00 X-33. Y0. G00 Z9. Z1. G01 Z-11. F500. X-28. F500. Y25. G02 X-25. Y28. I3. G01 X25. G02 X28. Y25. J-3. G01 Y-25. G02 X25. Y-28. I-3. G01 X-25. G02 X-28. Y-25. J3. G01 Y0. X-33. G00 Z9. M05 (DRILL1) M09 M01 G55 S5000 M03 M08 G00 X0. Y0. G00 Z22. Z2. G98 G73 X0. Y0. Z-11. R1. Q2. F500. G80 G0 Z22.

M30 %

phil-barrett commented 1 year ago

OK, tried it. Ran ioSender 2.0.42. Teensy 4.1 on a T41U5XBB with a 20230501 build. USB and Web Socket connections both ran the program and did not get an exception. Note, this is on a board that is not installed in a machine though that probably doesn't matter.

I'm kind of stabbing the dark but... M1 puts the controller into the Hold:0 state and doesn't act as a toggle. Strange that it would allow your program to continue. What build level of grblHAL are you running? (Console Ver statement)

Edit: I ran the program with an M1 before the G54 and it placed the machine in the HOLD:0 state. Cycle Start caused it to resume running. I believe this is correct behavior.

dontfeelcold commented 1 year ago

I I'm on ioSender 2.0.42. with Teensy 4.1 on a V2.09 T41U5XBB.

Here is what the console shows

[VER:1.1f.20230501:] [OPT:VNMSL+,35,1024,4,0] [AXS:4:XYZA] [NEWOPT:ENUMS,RT+,ES,REBOOT,EXPR,TC,SED,RTC,ETH] [FIRMWARE:grblHAL] [NVS STORAGE:*FLASH] [DRIVER:iMXRT1062] [DRIVER VERSION:230331] [DRIVER OPTIONS:USB.1] [BOARD:T41U5XBB] [AUX IO:4,3,0,0] [IP:192.168.5.1] [PLUGIN:MODBUS v0.14] [G54:0.000,0.000,0.000,0.000] [G55:0.000,0.000,0.000,0.000] [G56:0.000,0.000,0.000,0.000] [G57:0.000,0.000,0.000,0.000] [G58:0.000,0.000,0.000,0.000] [G59:0.000,0.000,0.000,0.000] [G59.1:0.000,0.000,0.000,0.000] [G59.2:0.000,0.000,0.000,0.000] [G59.3:0.000,0.000,0.000,0.000] [G28:0.000,0.000,0.000,0.000] [G30:0.000,0.000,0.000,0.000] [G92:0.000,0.000,0.000,0.000] [TLO:0.000,0.000,0.000,0.000] [PRB:0.000,0.000,0.000,0.000:0]

phil-barrett commented 1 year ago

I see three differences from the build I used to test:

dontfeelcold commented 1 year ago

I've used the web builder to generate the .hex. It seems I was selecting an option that was throwing things out. I'm not sure which one, possibly one in the advanced features.

Thanks for your help.

terjeio commented 1 year ago

In [NEWOPT...] we match up except for EXPR. Not sure which plugin that is. Maybe try with out it?

It is telling that parameters and expression support is enabled. The exception happens with my STM32F756 board even if it is not enabled.

[OPT:VNMSL2,35,1024,3,0] is slightly different from yours. Not sure why VNMSL2. I built with the web interface.

VNMSL2 : 2 shows up when a ganged/auto-squared axis is compiled in.

Still waiting for my new Teensy - PostNord has lost the package somewhere so I have no idea when it will arrive... I have been able to replicate the issue with the STM32F756 board but only with telnet comms, websockets is ok. And it is happening randomly so very hard to track down - perhaps a memory leak somewhere. BTW the ESP32 driver is ok - the telnet code is exactly the same but the underlying lwIP driver is not. What I am pretty sure about is that this is not a sender issue since the network stack in the controller simply ceases to work - grblHAL is still running but cannot be connected to since the telnet connection is still flagged as active.