STM32F103RET6 MCU Unhandled exception

[Killerplanet]

I'm currently having an issue trying to run iosender on my Nymolabs NBS6040 with the STM32F103RET6 MCU but while it tries to connect during startup I get an error stating "unhandled exception occurred: input string was not in a correct format." Any ideas on how I can fix this would be awesome.

[terjeio]

Nymolabs NBS6040 with the STM32F103RET6 MCU

Running grblHAL?

Can you try the latest edge build?

[Killerplanet]

I just tried the edge build but same issue. I believe the machine is just using grbl 1.1 but i thought iosender works with grbl and grblhal correct? Another odd thing i noticed is if i plug in the usb to the machine while the machine isnt powered up it will turn on just the mcu bord. Doing that gives me a different error in the included screen shot.

[phil-barrett]

I don't believe there is a grbl 1.1 port to the F103. The next thing to do is hook up a terminal app (like PuTTY) and see what it is sending, though the console tab may have enough to know what it is.

[Killerplanet]

Can you explain what I should be doing with PuTTY as i have never used it before. I tried connecting to the comport of the machine and i just get a black box with no information on the screen.

[phil-barrett]

You will need to select the port, baudrate, bits, parity and stop bits (probably 115200, 8, N, 1). Hit enter to wake it up.

But, check the console tab in ioSender after you get the error message.

[Killerplanet]

Putty wasnt doing anything and with ioSender I cant do anything because of the unhandled exception. I downloaded openbuilds control to get a connection to the machine and this is what displayed after connecting to the machine.

[11:49:04] [ $$ ] $0=10 (step pulse,usec) ;Step pulse time, microseconds

[11:49:04] [ $$ ] $1=255 (step idle delay,msec) ;Step idle delay, milliseconds

[11:49:04] [ $$ ] $2=0 (stepport invert mask) ;Step pulse invert, mask

[11:49:04] [ $$ ] $3=4 (dirport invert mask) ;Step direction invert, mask

[11:49:04] [ $$ ] $4=1 (stepenable invert,bool) ;Invert step enable pin, boolean

[11:49:04] [ $$ ] $5=1 (lims pin invert,bool) ;Invert limit pins, boolean/mask

[11:49:04] [ $$ ] $6=0 (probe pin invert,bool) ;Invert probe pin, boolean

[11:49:04] [ $$ ] $10=2 (status report mask) ;Status report options, mask

[11:49:04] [ $$ ] $11=0.010 (junction deviation) ;Junction deviation, millimeters

[11:49:04] [ $$ ] $12=0.002 (arc tolerance,mm) ;Arc tolerance, millimeters

[11:49:04] [ $$ ] $13=0 (report inches,bool) ;Report in inches, boolean

[11:49:04] [ $$ ] $20=0 (soft limits,bool) ;Soft limits enable, boolean

[11:49:04] [ $$ ] $21=1 (hard limits,bool) ;Hard limits enable, boolean

[11:49:04] [ $$ ] $22=1 (home cycle,bool) ;Homing cycle enable, boolean (Grbl) / mask (GrblHAL)

[11:49:04] [ $$ ] $23=0 (homing dir invert mask) ;Homing direction invert, mask

[11:49:04] [ $$ ] $24=100.000 (homing feed,mm/min) ;Homing locate feed rate, mm/min

[11:49:04] [ $$ ] $25=2000.000 (homing seek,mm/min) ;Homing search seek rate, mm/min

[11:49:04] [ $$ ] $26=250 (homing debounce,msec) ;Homing switch debounce delay, milliseconds

[11:49:04] [ $$ ] $27=1.000 (homing pull-off,mm) ;Homing switch pull-off distance, millimeters

[11:49:04] [ $$ ] $30=24000 (maximum spindle speed,rpm) ;Maximum spindle speed, RPM

[11:49:04] [ $$ ] $31=0 (minimum spindle speed,rpm) ;Minimum spindle speed, RPM

[11:49:04] [ $$ ] $32=0 (laser mode enable,bool) ;Laser-mode enable, boolean

[11:49:04] [ $$ ] $40=0 (parking enable,bool) ;Apply soft limits for jog commands, boolean

[11:49:04] [ $$ ] $41=0 (use corexy,bool) ;Parking cycle as bitfield where setting bit 0 enables the rest

[11:49:04] [ $$ ] $42=0 (turn off z home,bool) ;Parking axis

[11:49:04] [ $$ ] $100=1000.000 (X axis pulse:step/mm) ;X-axis steps per millimeter

[11:49:04] [ $$ ] $101=1000.000 (Y axis pulse:step/mm) ;Y-axis steps per millimeter

[11:49:04] [ $$ ] $102=1000.000 (Z axis pulse:step/mm) ;Z-axis steps per millimeter

[11:49:04] [ $$ ] $103=222.222 (A axis pulse:step/mm) ;A-axis steps per degree

[11:49:04] [ $$ ] $110=4800.000 (X axis max rata:mm/min) ;X-axis maximum rate, mm/min

[11:49:04] [ $$ ] $111=4800.000 (Y axis max rata:mm/min) ;Y-axis maximum rate, mm/min

[11:49:04] [ $$ ] $112=4800.000 (Z axis max rata:mm/min) ;Z-axis maximum rate, mm/min

[11:49:04] [ $$ ] $113=5000.000 (A axis max rata:mm/min) ;A-axis maximum rate, deg/min

[11:49:04] [ $$ ] $120=100.000 (X axis acceleration:mm/s^2) ;X-axis acceleration, mm/sec^2

[11:49:04] [ $$ ] $121=100.000 (Y axis acceleration:mm/s^2) ;Y-axis acceleration, mm/sec^2

[11:49:04] [ $$ ] $122=100.000 (Z axis acceleration:mm/s^2) ;Z-axis acceleration, mm/sec^2

[11:49:04] [ $$ ] $123=50.000 (A axis acceleration:mm/s^2) ;A-axis acceleration, deg/sec^2

[11:49:04] [ $$ ] $130=600.000 (X aixs max travel:mm) ;X-axis maximum travel, millimeters

[11:49:04] [ $$ ] $131=400.000 (Y aixs max travel:mm) ;Y-axis maximum travel, millimeters

[11:49:04] [ $$ ] $132=115.000 (Z aixs max travel:mm) ;Z-axis maximum travel, millimeters

[11:49:04] [ $$ ] $133=9999.000 (A aixs max travel:mm) ;A-axis maximum travel, degrees

[11:49:04] [ $$ ] ok

[11:49:04] [ $I ] [VER:V4.2.20240131:CUSTOM]

[11:49:04] [ $I ] [OPT:VZ0L,35,254]

[11:49:04] [ $I ] ok

[11:49:04] [ $G ] [GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F0 S0]

[11:49:04] [ $G ] ok

[11:49:05] [ connect ] Firmware Detected: gnea version 1.1f dated 20240131 on COM5

[phil-barrett]

Looks like a Chinese fork of Grbl. Weird that it starts with a dump of the settings.

[Killerplanet]

Any ideas on how to get it working with ioSender? As it stands now it crashes as soon as I open ioSender and i cant click anything in the program with the error message pop up.

[phil-barrett]

I'd be tempted to try loading grblHAL on the board. Getting ioSender working with the existing firmware is Terje's area though I wouldn't blame him for not wanting to do the work.

[Killerplanet]

I have no experience with compiling firmware or flashing custom software to PCBs. I tried following some of the guides but was unsuccessful with getting anything to work. The machine came with an offline grbl controller that allows me to flash firmware to the device but nothing seemed to work. Luckily, I am able to flash the firmware from the manufactures website to get the machine back to its original functioning order. Not sure if anyone can help me compile a firmware file that could possibly work with ioSender.

[terjeio]

They have added a description string after the setting value and this causes the error. I should trap that and ignore the setting - and then the sender should exit with a message about a non-compliant Grbl fork.

BTW the source code should be published somewhere if they respect the Grbl license, if they/you can provide a link I may either add support in ioSender or add a grblHAL map for the controller.

[Killerplanet]

Let me ask the manufacturer if they can provide this. You aren't talking about a firmware.bin file or windows driver correct?

[terjeio]

You aren't talking about a firmware.bin file or windows driver correct?

Correct, I am talking about the source code which they are obliged to publish.

[Killerplanet]

Well I emailed them and they don't want to provide it.....

[terjeio]

They have to, if not nobody should buy their equipment.

[Killerplanet]

I agree especially since they are using open source free software to create the firmware for the device. It would be one thing if it was proprietary code like some fanuc controller or something but its free to everyone to use. Im going to try to work with them to give it too me.

[phil-barrett]

The Chinese operate with a different set of ethics. Good luck getting them to actually release the code.

[Killerplanet]

yea well they said they dont produce the main board so they cant provide the source code....

[cbaugher]

I'm having this same issue with a SainSmart 3020ProMax V2. It uses a GD32F103CBT8 based board, which appears to be used on some of their other machines too. I haven't been able to find source code either.

I might be able to map the MCU pins to functions though, if that might help.

[kot0005]

looks like iosender for some reason wont work with hobby machines. I have a 3030 prover max. All other gcode senders work. So surely its some coding in iosender or iosender is exclusive to Grblhal and discription should probably updated to exclude if it doesnt work with latest version.

[kot0005]

https://www.sainsmart.com/blogs/news/basic-gcode-for-grbl-v2-0

https://www.sainsmart.com/blogs/news/grbl-v1-1-quick-reference

https://docs.sainsmart.com/article/zn73h7h6b6-uploading-firmware-on-a-sain-smart-cnc-controller

https://docs.sainsmart.com/article/fov840u38d-3030-prover-max

not sure if these links will be able to help with making iosender compatable with these machines

[kot0005]

also found this page where you can download the .bin firmware for these machines.

https://docs.sainsmart.com/article/jl1v6bt6lt-update-the-firmware-for-your-4040-pro-offline-controller

[kot0005]

I'm having this same issue with a SainSmart 3020ProMax V2. It uses a GD32F103CBT8 based board, which appears to be used on some of their other machines too. I haven't been able to find source code either.

I might be able to map the MCU pins to functions though, if that might help.

shouldnt need all that, CNC3D, Gsender, UGS and openbuilds sender all work with these machines. The only outlier here is Iosender which seems to only work with grblHal

[cbaugher]

I'm having this same issue with a SainSmart 3020ProMax V2. It uses a GD32F103CBT8 based board, which appears to be used on some of their other machines too. I haven't been able to find source code either.
I might be able to map the MCU pins to functions though, if that might help.

shouldnt need all that, CNC3D, Gsender, UGS and openbuilds sender all work with these machines. The only outlier here is Iosender which seems to only work with grblHal

So the problem here is that the Chinese machines pretty much all (as far as I know) use a fork of the original grbl firmware that doesn't behave exactly the same (...as the official grbl. IOSender does in fact support the official grbl). It wouldn't be a big deal if they would just publish their forked source code, AS THEY ARE LEGALLY REQUIRED TO DO. This way the gcode sender developers can examine the forked grbl source and understand exactly what changes are needed to support the machines. Without the source, the developers have to reverse engineer and/or guess about what changes are needed to support these machines, which means they may or may not work reliably. Publishing the source code benefits everyone as it helps to foster reliability and compatibility between machines and software. But as mentioned, the Chinese mfgrs don't seem to want to follow the rules. So it's understandable that Terje isn't too keen on supporting their machines. Honestly I kind of share his POV.

Anyway, for the 3020, I did map as many of the IO pins as I could. So grblhal could (in theory) be updated to support that board for probably 90% of its functionality. But it turns out updating the firmware isn't straightforward because there's no jumper to put it into DFU mode, nor is there an SD card slot to update it that way. The only option (I think) is an in circuit programmer. And upon discovering that I decided it wasn't worth the effort to continue with the existing control board.

To make life easier I bought an SKR Pico from BTT, which is supported by grblhal. An external spindle control board is needed, but that was easy enough to find. The Pico is actually easy to update and has TMC2209 drivers which are much quieter anyway. I lose the offline controller but that's irrelevant because it's going to be connected to a sender anyway.

C|

[terjeio]

looks like iosender for some reason wont work with hobby machines. I have a 3030 prover max. All other gcode senders work. So surely its some coding in iosender or iosender is exclusive to Grblhal and discription should probably updated to exclude if it doesnt work with latest version.

I does not work with bastardized Grbl forks that are not compliant with the original specification, undocumented and in breach of the license. And I see no reason to support such forks due to this and also not having access to a board that I can use for testing.

I have hardened the code so that the sender should no longer crash when reading the settings, I'll publish an edge version when I get time. However, since setting values are unreadable due to the text added to them it is unlikely that ioSender will behave correctly and/or with full functionality. This is due to the fact that ioSender configures itself from a number of the setting values.

If/when the board supplier provides documentation and publishes the source I'll try to add full support.

[kot0005]

I'm having this same issue with a SainSmart 3020ProMax V2. It uses a GD32F103CBT8 based board, which appears to be used on some of their other machines too. I haven't been able to find source code either.
I might be able to map the MCU pins to functions though, if that might help.

shouldnt need all that, CNC3D, Gsender, UGS and openbuilds sender all work with these machines. The only outlier here is Iosender which seems to only work with grblHal

So the problem here is that the Chinese machines pretty much all (as far as I know) use a fork of the original grbl firmware that doesn't behave exactly the same (...as the official grbl. IOSender does in fact support the official grbl). It wouldn't be a big deal if they would just publish their forked source code, AS THEY ARE LEGALLY REQUIRED TO DO. This way the gcode sender developers can examine the forked grbl source and understand exactly what changes are needed to support the machines. Without the source, the developers have to reverse engineer and/or guess about what changes are needed to support these machines, which means they may or may not work reliably. Publishing the source code benefits everyone as it helps to foster reliability and compatibility between machines and software. But as mentioned, the Chinese mfgrs don't seem to want to follow the rules. So it's understandable that Terje isn't too keen on supporting their machines. Honestly I kind of share his POV.

Anyway, for the 3020, I did map as many of the IO pins as I could. So grblhal could (in theory) be updated to support that board for probably 90% of its functionality. But it turns out updating the firmware isn't straightforward because there's no jumper to put it into DFU mode, nor is there an SD card slot to update it that way. The only option (I think) is an in circuit programmer. And upon discovering that I decided it wasn't worth the effort to continue with the existing control board.

To make life easier I bought an SKR Pico from BTT, which is supported by grblhal. An external spindle control board is needed, but that was easy enough to find. The Pico is actually easy to update and has TMC2209 drivers which are much quieter anyway. I lose the offline controller but that's irrelevant because it's going to be connected to a sender anyway.

C|

No no, I am just confused to why other senders work with these machines but not Iosender.

Opensource code will always be exploited by chinese companies unfortunately.

[kot0005]

e hardened the code so that the sender should no longer crash when reading th

looks like iosender for some reason wont work with hobby machines. I have a 3030 prover max. All other gcode senders work. So surely its some coding in iosender or iosender is exclusive to Grblhal and discription should probably updated to exclude if it doesnt work with latest version.

I does not work with bastardized Grbl forks that are not compliant with the original specification, undocumented and in breach of the license. And I see no reason to support such forks due to this and also not having access to a board that I can use for testing.

I have hardened the code so that the sender should no longer crash when reading the settings, I'll publish an edge version when I get time. However, since setting values are unreadable due to the text added to them it is unlikely that ioSender will behave correctly and/or with full functionality. This is due to the fact that ioSender configures itself from a number of the setting values.

If/when the board supplier provides documentation and publishes the source I'll try to add full support.

upto you man, its your application. A lot of people use these machines. I am just confused to why the other senders work with the chinese cnc's. Are other senders not complying with original GRBL ?

I would like to upgrade to grblhal with experia electronics but a bit too expensive atm. I have an spare octopus pro machine but my 3030 prover max is compatible with a encoder/pendant and no way to connect something similar to an octopus pro

[terjeio]

Opensource code will always be exploited by chinese companies unfortunately.

And why then making it easier for them to get away with it by supporting their illegal products?

Are other senders not complying with original GRBL ?

It depends on how they parse setting values and if they support string settings which is an grblHAL extension.
If they just extract the numeric value ignoring whatever follows then the added comment does not matter, but since ioSender supports grblHAL, and thus string values, it does. I know about one sender that had to modify its settings parser to strip away the extra characters before parsing. A side effect of this might be that previous, perhaps unintended, support for grblHAL string settings (SSIDs, passwords etc) is gone...