VERY old machine - need GCode customisation beyond GCodeBase.js

Discussions around the CAM Add-On of QCAD.

Moderator: andrew

Post Reply
luz
Newbie Member
Posts: 4
Joined: Sat Nov 16, 2019 8:22 pm

VERY old machine - need GCode customisation beyond GCodeBase.js

Post by luz » Sat Nov 16, 2019 9:22 pm

Hi,

I'm trying to create a post-processor for a really old CNC Machine, a BANDIT 8300. This machine does use a dinosaur version of GCode with a lot of details that differ from more recent machine's more standardized GCode as covered by the configuration visible GCodeBase.js.

To get the BANDIT to work, I'd need deeper customisation. As it is also a bit of a reverse engineering thing (the BANDIT's docs are not so clear on the G-Code level), I'm not yet sure about everything I'll need in the end, but at the moment the obstacles are:
  • All numbers need to have a decimal point, even if all fractional digits are 0 (because if the decimal point is missing, the machine interprets the number as 1/1000th mm. Example 5.5 -> 5.5mm, 5. -> 5mm, but 5 -> 0.005mm).
  • G2/G3 do not work as in newer G-Codes, these are for quarter and full circles only. There is a different syntax for partial arcs, but these must remain within a single quadrant. So I probably need to override arcExport() to split longer arcs at quadrant borders.
  • There are no G0 and G1 commands. The differentiation between rapid and "contour" moves is done by using IJK for rapid moves. So I'd need a way to output "xPosition"/"yPosition" as IJ.
I could probably figure out all of the above, if I could see the Code of the CamExporterV2 base class. But apparently this is not contained in a .js file within the app or the open source repos.

Thanks for any hints how I can proceed to get that nice old BANDIT run QCAD output!

CVH
Premier Member
Posts: 301
Joined: Wed Sep 27, 2017 4:17 pm
Location: Belgium; Antwerp

Re: VERY old machine - need GCode customisation beyond GCodeBase.js

Post by CVH » Sat Nov 16, 2019 11:15 pm

Hello,
Looked up Bandit 8300 controller.

Without pictures or knowing your setup:
These dinosaurs are usually of a very good mechanical construction.
If the major importance would be to preserve it in total, I can understand your approach strategy.
If not, I would simply retrofit the controller.

This does not have to cost an arm and a leg, even when not Mach3/4, nor knockoffs, nor chinese.
For a few hundreds Euro/Dollar you can make a quantum leap into the present.

Electronics has made several immense steps forward meanwhile.
Actuator and splindle driver technology is no longer analog and is very versatile and robust.
No longer do we use resitive driving, we chop very high voltages with fast inductance change.
Thinking of microstepping, step-loss, backslash .... hunting .... cooler, efficient and much less noisy.
These days we even can tune away low, mid and high range natural oscillation.

For sure, any elco's older than 15-20 years does need replacement,
certainly when bulging and preffered when not powered for a long time.
Also look for underdimensioned resistors.
You might find darker sections on the printed circuits scorch by the execive heat.
If the colorcode is still visible it is best to swap them because the resitance may be off.

Besides that, be aware that the mains voltage has increased the last several decades.
Here in Belgium AC220v +/-10% has changed to 240v +/-10% in two steps. Same goes for triphase 380 AC.
Usually my multi will display 260 and some volts AC.

It is not the first older appliance that ends with a smoke plume...
... after a while.
Worked a lot with similar situations, saw many disasters too.
(Last one was a LM7805 that got a little too high transformend input from the mains)

Regards,
CVH
QCADpro 3.23.0.0 / win7pro 32 bit / 4GB / 1e generation i7 2.6Ghz / HDD GeForce GT 520

luz
Newbie Member
Posts: 4
Joined: Sat Nov 16, 2019 8:22 pm

Re: VERY old machine - need GCode customisation beyond GCodeBase.js

Post by luz » Sat Nov 16, 2019 11:52 pm

Thanks for your comments.
If this was a machine sitting in a corner in unknown overall state - you'd be right.

But this is a machine in daily use by its owner (not me) - the hardware is fully ok, there is a company here who can and did provide service for it (and yes, some Elkos had to be replaced some time ago). The hardware is fully ok.

It's just that with manual input only, it is hard to use for complex tasks.

Maybe retrofitting a new controller would work. But this is an extremely high precision watch maker milling machine, which has cost a fortune back in its days, and is a bit special in many ways. I doubt the original spindle motors would work with a new controller easily, and replacing them would be very difficult mechanically.

So given the extreme flexibility built into QCAD's CamExporterV2 class, I'd rather use that to tweak the G-Code a bit. It's not a lot that needs to be done in the exporter, it's just difficult to do without knowing a bit more about the details of CamExporterV2 ;-)

luz
Newbie Member
Posts: 4
Joined: Sat Nov 16, 2019 8:22 pm

Re: VERY old machine - need GCode customisation beyond GCodeBase.js

Post by luz » Sun Nov 17, 2019 10:31 am

Got a big step further
Found the debugger and with it, the possibility to look into CamExporterV2() :-)

Now trying to override exportArc()...
[Update] No, not even needed! There's a flag `splitArcsAtQuadrantLines` which already does the trick!
And the `trailingZeroes` option solves the problem with non-fractional coordinates.
Even rapid move with I/J instead of X/Y was easy in the end - just registering new X_RAPID,Y_RAPID variables on xPosition/yPosition that output as I/J, and then using those in the rapid move templates.

So basically, I think this should now work with the BANDIT. Testing on the hardware will show...
Once it works, I'll post it here.

luz
Newbie Member
Posts: 4
Joined: Sat Nov 16, 2019 8:22 pm

Re: VERY old machine - need GCode customisation beyond GCodeBase.js

Post by luz » Sun Nov 17, 2019 9:47 pm

It works, for real, on the BANDIT! :-)

The last obstacle was that the exporter generated some lines only containing a Nxxx line number. Sounds harmless, but isn't, on the BANDIT - Nxxx without further commands are treated as GOTO xxx.
I found that CamExporterV2.prototype.writeBlockFromString() has code to prevent this, but apparently there's a bug that lets some number-only lines slip trough. So I had to add an override for writeLine() with another check.

But now, to all the millions of BANDIT + QCAD users out in the world: here's the postprocessor script for you :wink:

https://github.com/plan44/p44banditd/bl ... eBandit.js

(Of course, there might still be bugs, so be careful. And certainly there's room for further optimisation)
I tested the script only with QCADCAM-Pro 3.23.0.0 on macOS 10.14.6.

Post Reply

Return to “QCAD/CAM”