More outputs!

[Rando]

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 .

The PilotFish Front panel

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.

The rear, showing the Form-C blocks, remote jacks, and indicator LEDS.

The remote-actuator. 20A at 120VAC :D

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

[BillK]

I'm speechless, amazing!

[bill z]

Rando,

This is really great!

Your background must have given you the edge to know how to apply the G-Code to the arduino processor and then how to apply and add to the arduino circuits to handle the current needs.

Have you thought about just making a controller that does all of this automagically using just the output from your BobCAD? Think about it. The NWA controller has 3, maybe 4 channels where your 'add-on' has 10 and some of them are not used. Seems it is sort of backwards.

With the arduinos, the Pine64s, and the Raspberry PIs and the other PIs should't it be relative easy to build a controller doing all? Please understand that I am somewhat ignorant in this stuff. I do 'dink around' with the PIs but no where near your level. I sort of get stuck along the way and frequently need help. I'm betting several of us wishes for tutoring in this.

Thanks for your inspiration.

[Rando]

Rando,

This is really great!

Your background must have given you the edge to know how to apply the G-Code to the arduino processor and then how to apply and add to the arduino circuits to handle the current needs.

Have you thought about just making a controller that does all of this automagically using just the output from your BobCAD? Think about it. The NWA controller has 3, maybe 4 channels where your 'add-on' has 10 and some of them are not used. Seems it is sort of backwards.

With the arduinos, the Pine64s, and the Raspberry PIs and the other PIs should't it be relative easy to build a controller doing all? Please understand that I am somewhat ignorant in this stuff. I do 'dink around' with the PIs but no where near your level. I sort of get stuck along the way and frequently need help. I'm betting several of us wishes for tutoring in this.

Thanks for your inspiration.

Yeah, Electronics Engr (not power-plant type Electrical) doing Chip layout/HW/SW/Embedded for, oh, about 38 years now . Been doing programmer-type documentation since about 2000; that there's a WAY easier job!

Questions about "why didn't you just...." are always difficult to answer for involved systems. It's like asking a Army General whether he thought he'd have gone farther in the Air Force. I mean, if we really want to keep it simple, I'd have just plugged two power-strips (with switches!) in parallel to the router output, and bought a bunch of spare fuses....LOL...and I know some engineers who would do just that....like ME, before I made this .

The specific hows and whys of whether one solution architecture is chosen over another is a very long topic of discussion. For this design, you can chalk up many implementation choices to one of either "because that's how I wanted to make it", or "because I already had those parts", or "because that's f-in COOL!"

WRT using a different platform (but keeping the current design architecture), the Pi's by-default run Debian Linux, which is far away from a real-time operating system. So, in this case, given the number of outputs, the consistently fast response time desired, and that I already had the board on hand, it was an easy choice.

WRT just building-out a new controller...we call that "scope creep", where a design grows in features because they **can** be added, not because they **should**. The CNC controllers with the number of outputs and features I **want** are the $20K Haas kind. That one can be expanded to 400+ channels, IIRC. What I **need** is to be able to control things in synchrony with the GCode execution, yet also turn them on and off manually and when the CNC controller is OFF. What I **don't** need is the work required to change over all my CAD and workflow systems to produce GCode tuned for a new controller that might or might not have the features I rely on, the reliability, and whole bunch of other things that are currently well-understood.

For example, consider the compressor. It's about 50-feet away from my CNC work area, upstairs, outside, in the garage. When it's 70F outside, I'm happy to go outside and turn it on. But not when it's 20F at 6am like it's been here this Winter. I use shop air both to drive the mister and to run normal pneumatic air tools like a blower nozzle, screwdrivers and die grinders. If I had built it all as unified controller, I'd have to turn on the CNC to use the shop air. Nah, that won't work; I want independent manual control of that one.

By building an independent system, what I made stays my responsibility, and what NWA (or any other controller mfg) made stays theirs. If you consider that when compared to a full-on controller, my additions are in the range of 1-2%, I'd still have to spend the full 100% testing time for all that code I didn't write. To heck with that! I'll make sure my stuff works, and as long as NWA's controller does what it's been doing since I got it, my code will work just fine. Plus, this way I have someone besides myself to fling blame at when it all goes wrong .

To be honest, one of the design goals for this was to get all the functionality I wanted, as fast as possible, as cheaply as possible, without disrupting existing production or unnecessarily duplicating purchased hardware. This, after all, isn't the actual project I'm working on. No, this is a project needed to allow the machine to run nearly autonomously, producing MONEY while I work on my actual product designs, which due to government regulations, must remain hush-hush for now. The entire project took a little over four weeks, start to finish, including feasibility study, design, build, code, test, and integrate.

Hope that gives some insight.

Regards,

Thom