More outputs!
Posted: Fri Jan 27, 2017 1:44 pm
Hey, y'all:
If you've noticed my odd posts around these parts, you know I use my Shark HD2+ to cut aluminum. Okay, I do some plastic, and I'll even mechanically etch a PCB on it. But by and large, I do aluminum. Which poses a problem: when cutting aluminum, it requires a chip-blower to remove those cut chips from the area, so they don't get re-cut and chip the cutting surfaces. Okay, so there's a blower. And a vacuum for the rare wood cutting. Next up is a mister/spritzer that sprays little bursts of lubricant. It needs to be "on", but only for 1/4s ever 4-5 seconds. Next up, there's that spindle/router. And lights. Oh, and the compressor way away in the garage...I don't want to have to go out and turn it on and off every day....
Can you see where this is going? POWER! Specifically, power CONTROL, and power UNDER control of the CNC. I tend to plan and run multiple toolpaths from a single large file; many times one of the paths will want the mister, but it's totally useless for other cuts. So ideally, I want to have my GCODE turn all those devices on and off....FROM THE CONTROLLER, during the run. I don't WANT to stand there and turn the mister on and off. I don't WANT to pulse the blower once every 20 seconds during an engraving run. No, I want the machine to do all that itself
.
Yeah, you're probably saying he's daft. Can't argue with you there. But, I DID piece together a totally cool system that lets my GCODE turn on and off all those devices...up to 10 different channels...FROM THE GCODE. And, even, those commands are inserted by the post-processor
.
Attached are a couple pictures of this short project I lovingly called "Pilotfish", after the fishies that follow Sharks
.
In this picture of the front-panel, channels 1-4 are programmed, with channel 3 being passthrough. Channel 10 is ON, and channels 5-9 are currently disabled.
It works like this: the circuit intercepts the logic signal from the controller board to the solid-state-relay, and there's an Arduino processor watching that pin. (I mostly use BobCAD, not Vectric, sorry) When I'm making the toolpaths in BobCAD, there's a drop-down for type of coolant, with five options: OFF, Flood, Mist, Air, and Oil. I specify the GCODE to be produced when those options are selected, in the BobCAD post processor file. For each type, the GCode output inserts a GCode comment, like "(COOLANT-ON:MIST)" to turn on the mister, and "(COOLANT-OFF:MIST)" to turn it off. I also added a "(COOLANT-PULSE:ON and OFF)", but more on that later.
The arduino is programmed to turn on and off any of 10 different channels. Each channel has a high-current "local" Form C (NC, COM, NO contacts) that can handle 10A at ~28-30V. The other output for each of the 10 channels is a low-current reed relay attached to an 1/8" headphone jack. Using long audio-grade cables, can attach a remote unit to a far-away tool like the compressor, and have it controlled from the main unit. Those cables connect to remote actuation units, able to supply 20A at 120VAC. The HUGE benefit to this, over putting a power-strip onto that solid-state relay, is that the power that runs the tools does NOT go through the controller, and doesn't even have to be on the same wiring circuit as whatever is being controlled.
Yeah, I know, wireless, blah blah blah. I chose not to, based on wanting to avoid interference and potential security vulnerabilities.
Remember those comments inserted by the post-processor? Well, when it comes out of the CAM tool, I run my GCode through a custom tool that I wrote that does a variety of manipulations on the GCode. I like to call it "splatter-gather", as that is its primary function: to split apart the all-toolpaths-in-one-file output from BobCAD, then when desired and feasible, combine them back together into steps and operations, and add in other external files for pausing (e.g., to change/move the part) and for the power-control actions. As t processes the GCode, it detects those commands and replaces them with the contents of a file, specified in a "coolant types" file. Inside each of the power-control files, then, the GCode turns on and off the spindle output, using multiple M03/M05 pairs. Each pair produces a 70ms pulse with ~35ms HIGH (the M03). That's as fast as the controller will go
.
The arduino filters those short pulses out, and sends back to the controller the steady-state signal to turn on and off the router motor like is normally done. So, old toolpaths that don't have the power control commands still work properly. When the input signal is steady high, any channel configured as "passthrough" will also become enabled, as does the signal going back to the controller (to turn on that SSrelay). So, do you need a vacuum and another applicance both on during a cut? Just set both channels to passthrough, and it just plain works.
The truly cool, key piece, however, happens when GCode is run through the controller. When it arrives at the power-control commands, it toggles the motor-on off, and those pulses are counted by the PilotFish. Each command corresponds to a specific number of pulses: 1 = ignore as glitch, 2-11 = ON, 12=ON ALL, 13-22 = OFF, 23= OFF ALL, 24..33= PulseA, 34=PulseA ALL, and so on....When the Pilotfish sees the proper number of pulses, with the appropriate "dead space" around them, it does what it's commanded.
Each channel can be programmed as either Always ON, Always OFF (aka Disabled), Programmed (by the CNC), and Passthrough (from the CNC). The settings are stored in non-volatile memory, so it returns to the same state when you turn it back on. You can even LOCK a channel so it can't be changed until the lock is turned off. No, there's no password, it's just to keep inadvertent actions from changing states or configuration.
For my mister, like I mentioned, it needed a short pulse every few seconds. I have a cute little timer module that I've been using, but I found that the Arduino can give millisecond-accurate pulses out the ten channels. Each channel has two available pulse modes, A and B. The modes are essentially identical, but allow for, say, a fast and slow setting on a specific channel. Each channel's settings are separate; each setting has an ON time and an OFF time, and polarity parameters. ON times range from 50ms to 30s, and OFF times from 1s to 30min. Those settings will allow me to get rid of the timer module, simplifying the system.
The biggest expense of the project was 3D printing the main case, which took over 80 HOURS and 1.5Kg of PLA to print
. Sure...a $1200 glorified power strip...everyone will want one! LOL....NOT
.
If people are interested, I'm willing to submit/provide the plans, but they are extensive: 5 3D-printed parts, a mechanically-etched PCB, an Arduino Mega2560 and 16x2 LCD with 2k lines of code, a custom button panel, and a custom harness into the Shark Control panel, ten remote actuation modules, lots and lots of hand wiring and soldering, post-processor file updates/changes, not to mention mapping the physical outputs to the logical coolant types (that are available in the CAM program). If you need this capability, it is possible, but NOT easy or simple. That said, getting the design into a "presentable" form, like an open-source project, with parts lists and instructions, is not in the cards at the moment, so it would be pretty raw design models and code. Though I do tend to over-comment code
(you could guess that from the length of this post, right?)
Regards to all,
Thom
If you've noticed my odd posts around these parts, you know I use my Shark HD2+ to cut aluminum. Okay, I do some plastic, and I'll even mechanically etch a PCB on it. But by and large, I do aluminum. Which poses a problem: when cutting aluminum, it requires a chip-blower to remove those cut chips from the area, so they don't get re-cut and chip the cutting surfaces. Okay, so there's a blower. And a vacuum for the rare wood cutting. Next up is a mister/spritzer that sprays little bursts of lubricant. It needs to be "on", but only for 1/4s ever 4-5 seconds. Next up, there's that spindle/router. And lights. Oh, and the compressor way away in the garage...I don't want to have to go out and turn it on and off every day....
Can you see where this is going? POWER! Specifically, power CONTROL, and power UNDER control of the CNC. I tend to plan and run multiple toolpaths from a single large file; many times one of the paths will want the mister, but it's totally useless for other cuts. So ideally, I want to have my GCODE turn all those devices on and off....FROM THE CONTROLLER, during the run. I don't WANT to stand there and turn the mister on and off. I don't WANT to pulse the blower once every 20 seconds during an engraving run. No, I want the machine to do all that itself
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
Yeah, you're probably saying he's daft. Can't argue with you there. But, I DID piece together a totally cool system that lets my GCODE turn on and off all those devices...up to 10 different channels...FROM THE GCODE. And, even, those commands are inserted by the post-processor
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
Attached are a couple pictures of this short project I lovingly called "Pilotfish", after the fishies that follow Sharks
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
In this picture of the front-panel, channels 1-4 are programmed, with channel 3 being passthrough. Channel 10 is ON, and channels 5-9 are currently disabled.
It works like this: the circuit intercepts the logic signal from the controller board to the solid-state-relay, and there's an Arduino processor watching that pin. (I mostly use BobCAD, not Vectric, sorry) When I'm making the toolpaths in BobCAD, there's a drop-down for type of coolant, with five options: OFF, Flood, Mist, Air, and Oil. I specify the GCODE to be produced when those options are selected, in the BobCAD post processor file. For each type, the GCode output inserts a GCode comment, like "(COOLANT-ON:MIST)" to turn on the mister, and "(COOLANT-OFF:MIST)" to turn it off. I also added a "(COOLANT-PULSE:ON and OFF)", but more on that later.
The arduino is programmed to turn on and off any of 10 different channels. Each channel has a high-current "local" Form C (NC, COM, NO contacts) that can handle 10A at ~28-30V. The other output for each of the 10 channels is a low-current reed relay attached to an 1/8" headphone jack. Using long audio-grade cables, can attach a remote unit to a far-away tool like the compressor, and have it controlled from the main unit. Those cables connect to remote actuation units, able to supply 20A at 120VAC. The HUGE benefit to this, over putting a power-strip onto that solid-state relay, is that the power that runs the tools does NOT go through the controller, and doesn't even have to be on the same wiring circuit as whatever is being controlled.
Yeah, I know, wireless, blah blah blah. I chose not to, based on wanting to avoid interference and potential security vulnerabilities.
Remember those comments inserted by the post-processor? Well, when it comes out of the CAM tool, I run my GCode through a custom tool that I wrote that does a variety of manipulations on the GCode. I like to call it "splatter-gather", as that is its primary function: to split apart the all-toolpaths-in-one-file output from BobCAD, then when desired and feasible, combine them back together into steps and operations, and add in other external files for pausing (e.g., to change/move the part) and for the power-control actions. As t processes the GCode, it detects those commands and replaces them with the contents of a file, specified in a "coolant types" file. Inside each of the power-control files, then, the GCode turns on and off the spindle output, using multiple M03/M05 pairs. Each pair produces a 70ms pulse with ~35ms HIGH (the M03). That's as fast as the controller will go
![Sad :(](./images/smilies/icon_e_sad.gif)
The arduino filters those short pulses out, and sends back to the controller the steady-state signal to turn on and off the router motor like is normally done. So, old toolpaths that don't have the power control commands still work properly. When the input signal is steady high, any channel configured as "passthrough" will also become enabled, as does the signal going back to the controller (to turn on that SSrelay). So, do you need a vacuum and another applicance both on during a cut? Just set both channels to passthrough, and it just plain works.
The truly cool, key piece, however, happens when GCode is run through the controller. When it arrives at the power-control commands, it toggles the motor-on off, and those pulses are counted by the PilotFish. Each command corresponds to a specific number of pulses: 1 = ignore as glitch, 2-11 = ON, 12=ON ALL, 13-22 = OFF, 23= OFF ALL, 24..33= PulseA, 34=PulseA ALL, and so on....When the Pilotfish sees the proper number of pulses, with the appropriate "dead space" around them, it does what it's commanded.
Each channel can be programmed as either Always ON, Always OFF (aka Disabled), Programmed (by the CNC), and Passthrough (from the CNC). The settings are stored in non-volatile memory, so it returns to the same state when you turn it back on. You can even LOCK a channel so it can't be changed until the lock is turned off. No, there's no password, it's just to keep inadvertent actions from changing states or configuration.
For my mister, like I mentioned, it needed a short pulse every few seconds. I have a cute little timer module that I've been using, but I found that the Arduino can give millisecond-accurate pulses out the ten channels. Each channel has two available pulse modes, A and B. The modes are essentially identical, but allow for, say, a fast and slow setting on a specific channel. Each channel's settings are separate; each setting has an ON time and an OFF time, and polarity parameters. ON times range from 50ms to 30s, and OFF times from 1s to 30min. Those settings will allow me to get rid of the timer module, simplifying the system.
The biggest expense of the project was 3D printing the main case, which took over 80 HOURS and 1.5Kg of PLA to print
![Sad :(](./images/smilies/icon_e_sad.gif)
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
If people are interested, I'm willing to submit/provide the plans, but they are extensive: 5 3D-printed parts, a mechanically-etched PCB, an Arduino Mega2560 and 16x2 LCD with 2k lines of code, a custom button panel, and a custom harness into the Shark Control panel, ten remote actuation modules, lots and lots of hand wiring and soldering, post-processor file updates/changes, not to mention mapping the physical outputs to the logical coolant types (that are available in the CAM program). If you need this capability, it is possible, but NOT easy or simple. That said, getting the design into a "presentable" form, like an open-source project, with parts lists and instructions, is not in the cards at the moment, so it would be pretty raw design models and code. Though I do tend to over-comment code
![Wink ;-)](./images/smilies/icon_e_wink.gif)
Regards to all,
Thom