Bad Number Format

(Sean Schwartzenburg) #1

This is the second time in less than 24 hours I have had this message while trying to cut a design. I restarted the program and got past the issue the 1st time. Then while running the program the 2nd time over night I woke to this beauty…
A pop up window that stated " Bad Number Format."

It is bad enough that it takes 24hours of cutting for this 1 program but now I have to start over again for the 3rd time…and hope it doesn’t crash…
I have had other issues with Carbide Motion loosing communication for some reason during my over night cuts…
Anyone have a cure?

(William Adams) #2

Run the file through Grbl in simulation mode first.

$C - Check gcode mode

This toggles the Grbl’s gcode parser to take all incoming blocks and process them completely, as it would in normal operation, but it does not move any of the axes, ignores dwells, and powers off the spindle and coolant. This is intended as a way to provide the user a way to check how their new G-code program fares with Grbl’s parser and monitor for any errors (and checks for soft limit violations, if enabled).

When toggled off, Grbl will perform an automatic soft-reset (^X). This is for two purposes. It simplifies the code management a bit. But, it also prevents users from starting a job when their G-code modes are not what they think they are. A system reset always gives the user a fresh, consistent start.

I’ve suggested/argued that there should at least be an option in a comm / control program to do a hash of a file, and compare it to a list of stored hashes — if not found, run the job in check mode first, then if successful, add the hash to the list.

That said, I have to ask that you not let the machine run overnight / unattended:

Have you tried running your code through a G-Code optimizer?

or a simulator to see if there are places where it can be broken up into manageable chunks?

(Sean Schwartzenburg) #3

I will check it out. I am new to this machine and programing so to say I am a rookie is an understatement. The design took over 24hrs of constant cutting the last time I did it and was frustrating to say the least. I just need to get more comfortable with the feeds/speeds and turn them up so that it will not take as long. Using the .032 #122 bit takes forever!
If the Machine has run over night I have a timer set up on it to turn off 30min after the program should have run its’ course.

(William Adams) #4

The time estimates can be pretty rough — it might be that your timer is turning the machine off while the job is still running causing the error. Please don’t leave it running unattended (I will now stop pestering you about this).

We have official numbers at:

Setting up the proper feeds and speeds helps a lot — use the testing technique from:

There are a couple of saved .tps files at: (those are mostly for the Nomad).

Roughing w/ a square endmill, or larger one if possible will speed things up a lot.

Another option is to trick MeshCAM into making 4 separate passes:

  • set up the job using a 1/8" square and ball endmill as one normally would for two passes
  • dupe the file and change it to a 1/8" ball followed by a 1/16" ball — save only the latter pass
  • repeat, but pair the 1/16" w/ a 1/32nd

(there may be a better way to do that, but that’s what I came up w/ the last time I was looking into this sort of thing)