CR command went doolalley today

[rhfurniture]

I have a new benchtop using v3.1.7 on win2k.
I ran a part file (used many times without hassle) that uses CR to cut mortices, and it acted most strangely. The file called for a pocket in 4 plunges. Each time it plunged to the required depth, then moved up/down to 2x plunge depth and cut the rectangle. Fortunately the bit was not broken, and zeros were not lost.
It repeated the problem using just the cr command (but without wood).
Closing and restarting solved the problem entirely.
Does this sort of thing happen often and is there any way to avoid it? Is it a (are there any) known problem with this software?
Also some current documentation (especially re programming) would be very very useful.
This is the only problem to date and I am generaly most pleased.

Regards,

Ralph.

[Brady Watson]

Ralph,
I think all of us have gone through that sort of 'glitch' once or twice. I had my spindle crash into the table the 1st month...no damage done, except to table and bit. I couldn't figure out what the story was and after a restart and a power cycle of the control box, everything was fine. It hasn't happened since.

I strictly use DOS for SB control...Mainly because DOS has never crashed on me and I have enough new things to learn before I use the Windows software. The control software for me, has been as rock solid as anyone could expect from a piece of software.


-Brady

[artisan]

I continuously see the Shopbot "dive" after "S" stopping it and "R" resuming and have not had the time to analyze or debug this problem. It seems that the "z" number is being doubled after the pause. Steps and/or location are not lost and the file will run accurately when started over. I have resorted to stopping the file and using "FG" to return to the spot. I have an upgraded PR, running the latest control software. This happens with cut files generated in several different programs and is almost certainly the control software. The files cut perfectly otherwise....any thoughts....D

[Brady Watson]

Darrell,
Is it possible that your file uses a variable for the Z depth value? My thoughts are that the variable's value may be doubled if it is not reset...Like it is somehow going back up to that part in the routine and adding the value to itself.

Just a thought...

-Brady

[gerald_d]

Hope that you guys are reporting these glitches to the factory as well?

[artisan]

Brady, that's what I believe must be happening too....just haven't had the time to really get into the code.....which I believe is on the Shopbot side of the equation anyway and possibly unaccessible. I've seen the Bot do this with files written in Artcam, Mastercam, Rams and Visualmill now, so, I'm relatively sure it's a control issue bug of some type.
The "Z" variable seems to be adding itself or doubling, rather than re-setting. This happens on both 2D and 3D files.....though not always....probably 50% of the time. If it were consistent, I could identify it more easily. I'm mostly curious to see if anyone else has experienced this....I've seen it mentioned in the forum before. If it is a bug....then I'll work it out with Shopbot. If not, I'd like to uncover the problem. It's a small thing with an easy enough workaraound. It's just annoying. Anyone else seeing their Bot "dive" after pausing it? Thanks much....D

[artisan]

And Gerald....No, I haven't said anything...until now....D

[Brady Watson]

Well the tricky part to all of this is actually making it a 100% repeatable error before contacting SB...If it's not consistently repeatable then I doubt anyone will be able to trap the error and fix it.

-Brady

[gerald_d]

But if 2 or more people report the same intermittent error, then the developers can be alerted to an area of the software that might need special attention.