Burny 3 going crazy, posts??

[El Mustachio]

Hello,

I'm new here, I've been watching the forum for awhile and have noticed you guys being referred to from cnczone as well. I'm hoping someone here can help. Thanks in advance.

I Went to run our CNC Plasma table today (C&G Taurus Table w/ HT2000 Hypertherm Torch) and the crazy thing just went all over the table. So I started trouble shooting it...

• Checked serial connections
• dumped memory
• loaded a proven program
• confirmed machine was nuts
• double check encoders/resolvers on rack
• checked "std shapes" at burny control
• "std shapes" run fine
• manual controls / jogs run fine
• checked sys data for serial com setting, good
• posted test program to machine
• saved same program back to PC

... And that's where I'm stumped. I'm comparing two instances of a post saved from the Burny to the PC. In theory the should be EXACTLY the same line for line. They are not. One Burny ---> PC version of the post has about 35 lines. Then next time we did this (same program) it all the sudden has about 25 lines. The original post as saved by SigmaNest had about 25 lines.

We made *no* comm changes or program changes between saving these posts back to the PC. The post with more lines was the one that went nutzo at the machine. This has been happening with multiple posts this morning. Has anyone else had this happen???

It's working correctly again now, but we haven't changed anything, that's what bothers me. Thanks.

[WSS]

Not a Burny user, but it looks like the post is sending the torch to home (N50X0Y0) or somewhere close to it between cuts. You might have a reference checkbox checked or something like that. It would seem erratic to have the machine "go home" (or "X0,Y0" don't know what 0,0 is on a burny) at intervals while running a post.

WSS

[El Mustachio]

Thanks WSS,

In this case I don't think it's a matter of a checkbox. The Burny 3 is a non PC control with very limited user input. It's pretty much a dumb control, program in = program run, with the Burny only capable of altering the program by adding a kerf.

The two posts in the picture I attached were from the same source g-code. No modifications were made to the post at the Burny, not even adding a Kerf (for testing purposes). The sample program was saved to the Burny and then immediately saved back to PC, two times (deleting the program between tries). The results should have been identical. Why one would come back with more lines has got us stumped so far. Like I said, no modifications were done to the post at the machine, simply save to and then save back.

I'm beginning to wonder if it has to do with some sort of internal memory issue in the Burny or a processor board glitch.