PM-1440GT PLC\VFD Conversion? Stupid?

[skcncx]

I was planning to build an e-stop subroutine that won't return to the main program until the right conditions are met.

Yes, that is my plan as well. Any fault, even if the software has told the VFD to run or not it will stay in that error state (turn off all run commands) until all switches return to neutral... run, jog, e-stop, any override switch is back to it's normal state.

E-stop and power outage and return of power are two different scenarios. The USP on the WJ200, only solves the power outage scenario and unattended restart when power returns and lathe controls are left in a run state. I'll have similar PLC logic.

My e-stop will effectively have two latching switches, maybe 3 to 4. One that tells the PLC it's been activated, which will open the relays vis software to the VFD's logical inputs but more importantly, it will open the circuit to the VFD logical input wires and the common (24vdc) that's controlling the logical input relays. That second part is the non software based stop. In that scenario, even if the PLC were to close/activate the run relay command, it'd would do nothing, because the circuity was opened/broken via the e-stop switch. Of course, you are trusting the VFD internal software as well.

I guess, e-stop could cut power to everything... but you lose it's ability for dynamic and fast braking if VFD loses power. To me, e-stop/panic... fast braking seems like a feature if you are unfortunately in this position. They do have another mode, I think it's GS1/GS3 but, if you activate that, it's by design to just let the motor spin down, no braking.

Not sure it would solve much, but I would have looked for a VFD with e-stop somewhat baked in... though the WJ200 and it's very common use on this site, is one main reason to continue to use it.

 

[Beantown]

Yes, that is my plan as well. Any fault, even if the software has told the VFD to run or not it will stay in that error state (turn off all run commands) until all switches return to neutral... run, jog, e-stop, any override switch is back to it's normal state.

E-stop and power outage and return of power are two different scenarios. The USP on the WJ200, only solves the power outage scenario and unattended restart when power returns and lathe controls are left in a run state. I'll have similar PLC logic.

My e-stop will effectively have two latching switches, maybe 3 to 4. One that tells the PLC it's been activated, which will open the relays vis software to the VFD's logical inputs but more importantly, it will open the circuit to the VFD logical input wires and the common (24vdc) that's controlling the logical input relays. That second part is the non software based stop. In that scenario, even if the PLC were to close/activate the run relay command, it'd would do nothing, because the circuity was opened/broken via the e-stop switch. Of course, you are trusting the VFD internal software as well.

I guess, e-stop could cut power to everything... but you lose it's ability for dynamic and fast braking if VFD loses power. To me, e-stop/panic... fast braking seems like a feature if you are unfortunately in this position. They do have another mode, I think it's GS1/GS3 but, if you activate that, it's by design to just let the motor spin down, no braking.

Not sure it would solve much, but I would have looked for a VFD with e-stop somewhat baked in... though the WJ200 and it's very common use on this site, is one main reason to continue to use it.

Cool. Yep, you are are are looking at this through the same lens. It's fun. Thank you for joining the conversation. You have made me feel less crazy.

I'm looking forward to seeing what you come up with as well.

 

[B2]

However, the reality is, unless your safety circuit kills power to the VFD, we are trusting a microcontroller\software in the VFD for our safety.

Unfortunately, there are no 100% safe systems. We can only minimize risk and we cannot foresee every possible situation! I have even seen the contacts on relays (contactors) weld themselves into the closed contact position preventing the relay's de-activation from shutting off power! In this case the air conditioner pump just kept running. The failure was not destructive as the house just kept getting colder! Usually the relays contacts fail in the open position as they get burnt, pitted, oxidized and dirty with use.

The safety concern that most bothers me is the one where one's clothes gets caught in the turning work/spindle dragging me into it. It happens so fast that I cannot even find the e-stop or hit the foot brake! So dress properly etc. At one point someone posted a poor video on HM of a guy getting his t-shirt tangled in the spinning lathe. He was hopping all over the place tying to get the lathe stopped. He finally got on a brake, but before that happen the old shirt, fortunately, ripped off of his back! Lesson learned: So if you are going to wear loose clothing around machinry then make sure it is rotten cloth!

VFDs are a computer controlling a high power delivery system. I doubt that even the tek reps know what the code really does. So who knows what the failure mechanism might be. Best, to use devices which have been proven by operation. In our case, the Hitachi VFD is widely used and is used for much larger motors than our little machines. It is my impression from reading that at some point VFDs just stop working and that a good portion of the time it is because the large capacitors in them that convert from AC to DC internally just wear out. This is not much of a safety concern when the motor just will not start up or has very little power.....

I had a older employee once, who liked to say "Man plans, God laughts!" I would guess that applies to our minimization of risk.

Dave L.

 

[skcncx]

@Beantown Likewise, curious to know what route you decide and what PLC system you use, if that's the route you choose.

Not to be pedantic, but my P1AM-100 arduino based is really just a microcontroller... I think PLC might be specific to the primary PLC programming languages like ladder logic and the few others I've heard of. In the end, though, equivalent concept, a processor reading and outputting state.

I was planning on using the VFD's internal 24 DC+ to be the common line for my PLC's sourcing output module, which are just solid state relays to the logical inputs on VFD. I now plan to use an external 24vdc power supply for VFD logical input circuitry. My e-stop will cut cut power at the 24v external supply entirely, both side of the logical inputs are affected. I can't cut power to the VFD's internal power supply... I don't think at least.

The thing about e-stop, panic stop, whatever, it's gotta be simple and 100% effective... like @B2 called out... the actual relays/ssr could fail in a locked position. Adding more moving parts to it, may be more problematic, only given you a sense it's more protective. Really stinks when your failure logic/circuit fails! I half thought about a large kick e-stop switch near my feet. If my machine tries to eat me, I may not have arms or hands to stop it... but hopefully my foot can cause a stop with a large target to hit... that's if in the moment of panic I remember it's there. Seems like a better place for the e-stop is hanging off the carriage then way to the left on headstock. In theory, may hands should/will always be by the controls on the carriage. Although, my first instinct it probably to reach for the run lever and switch it to the neutral position, my muscle memory and brain without thinking will be going through that motion every time I use the lathe.

 

[Beantown]

Not to be pedantic, but my P1AM-100 arduino based is really just a microcontroller... I think PLC might be specific to the primary PLC programming languages like ladder logic and the few others I've heard of. In the end, though, equivalent concept, a processor reading and outputting state.

If I go the PLC route, I was leaning towards the Automation Direct CLICK PLC Plus. I didn't even see the Arduino based one until you had mentioned it. That is quite attractive since I'm more familiar with the Arduino ISE. The ladder logic a typical PLCs use is pretty intuitive, but I'd rather use C++. I will be looking into the P1AM-100 for sure. As long as it has the same\similar components that make it safe to use in an industrial environment it should be gold. I had originally started to design my own just using an Arduino, but then I started to read about all the EMI issues a VFD can create so I backed away from that really quickly....plus I would have had to address the native voltage issues and all that mess. I would have ended up building a PLC from the ground up anyway.

I was planning on using the VFD's internal 24 DC+ to be the common line for my PLC's sourcing output module, which are just solid state relays to the logical inputs on VFD. I now plan to use an external 24vdc power supply for VFD logical input circuitry. My e-stop will cut cut power at the 24v external supply entirely, both side of the logical inputs are affected. I can't cut power to the VFD's internal power supply... I don't think at least.

The internal power supply will probably work, but I am planning to use an external just to play it safe. I couldn't find the specs on the internal power supply for my Yaskawa GA500, but I doubt it's much. I have seen to many sketchy things happen with hardware when it gets starved for power. I know it's just conjecture, but a 24v power supply is cheap and I'm a weirdo.

The thing about e-stop, panic stop, whatever, it's gotta be simple and 100% effective... like @B2 called out... the actual relays/ssr could fail in a locked position. Adding more moving parts to it, may be more problematic, only given you a sense it's more protective. Really stinks when your failure logic/circuit fails! I half thought about a large kick e-stop switch near my feet. If my machine tries to eat me, I may not have arms or hands to stop it... but hopefully my foot can cause a stop with a large target to hit... that's if in the moment of panic I remember it's there. Seems like a better place for the e-stop is hanging off the carriage then way to the left on headstock. In theory, may hands should/will always be by the controls on the carriage. Although, my first instinct it probably to reach for the run lever and switch it to the neutral position, my muscle memory and brain without thinking will be going through that motion every time I use the lathe.

I thought the same thing. The e-stop is in a weird location! The foot brake was the one feature that pushed me to get the 1440GT over the 1340GT. My wife even agreed it was a smart move! But then again, SHE was the one who made me buy a brand new Sawstop table saw. I was going to buy an old Delta Unisaw off Craigslist until she found out how many fingers were lost every year.

 

[skcncx]

I will be looking into the P1AM-100 for sure. As long as it has the same\similar components that make it safe to use in an industrial environment it should be gold. I had originally started to design my own just using an Arduino, but then I started to read about all the EMI issues a VFD can create so I backed away from that really quickly....plus I would have had to address the native voltage issues and all that mess. I would have ended up building a PLC from the ground up anyway.

The CLICK PLC looks nice... I downloaded their software, but felt overwhelmed by all the options.... though I didn't really give it a chance or look at any getting started.

I did a prototype on a welding positioner using an arduino nano ($10 clone) that had a rotary encoder, stepper modor, lcd screen for rpm and other start/stop functionality, a first time doing anything arduino. It was a try it on something real, even more in the land of unnecessary for a welding positioner. I learned that arduino, input_pullups were horribly prone to emi, phantom button presses and not rugged by any means. It wasn't the software, it was the hardware, my naive implementation and protection's (not) built in.

I then looked at https://www.rugged-circuits.com/ since they have ruggedized and added many industrial concepts/protections into the arduino product line. I started learning those little resistors and components were vital past the prototype it on my desk phase. That's a good option as well.

I then stumbled onto the Automatic Direct productivity 1000 series lineup. The P1AM-100 arduino based uses all the same Productivity 1000 shields I/O modules so you get the traditional 24v dc system but with their version of the Arduino MKR board/processor for programming. They also have a thing called "productivity blocks" for it... it's a visual programmer that auto generates your arduino c++.... though programming via point & click IMHO is painful, the auto generated code is never clear... though, if you don't know c++, it's a great tool.

The AD Productivity 1000 hit all the marks for me, cheap(er), I can use arduino, it's what I know, I can do desktop prototyping, coding on cheap hardware, proof of concept and easily map it to better hardware with little fuss. The reading and writing to I/O is nearly identical using their shields and i/o devices. The form factor is very compact and easily expandable. I only need the P1AM-100 and P1-15CDD2, that's $130. It needs 24vdc, they have a couple power supplies specifically for it, which I did buy the 100-240AC/DC to 24DC PSU, but not required, use your own 24 DC power.

I also ordered the P1AM-100 GPIO shield, which has the same protections as the rugged-circuits for direct connection to the arduino MKR board under the covers. Though I'm not even sure I need it, I went with their combo P1-15CDD2, 8 input, 7 output that will be the input/output of my switches and ssr to vfd logical inputs, all running 24vdc. The GPIO will only be used for a diagnostics output to an LCD panel... or I'll have different LED lights as indicators to the program state.

If not using it already, try the VS Code plugin for arduino development, it's a far better experience than the arduino IDE. FACTS engineering, the hardware people behind the P1AM-100 uses it and confirmed it works.

Plus 1 on the SawStop, I have one, nice table saw... but still gotta use common sense to not lop off fingers. I know people who have triggered them... far better outcome that without it... but not scratch or serious pain free.

 

[vvanders]

As someone who's written their fair share of C++/C/etc and worked with some of the Automation Direct PLCs(mostly P1000) I would lean away from Arduino things and towards dedicated PLCs.

You'll get a lot of things that are purpose built for these types of applications(PID loops, explicit fault paths, etc), I've seen enough code go sideways without extensive test suites to lean more towards the PLC direction.

I found ladder pretty straightforward and debugging "live" was much easier than the whole compile/build/flash loop.

 

[skcncx]

As someone who's written their fair share of C++/C/etc and worked with some of the Automation Direct PLCs(mostly P1000) I would lean away from Arduino things and towards dedicated PLCs.

You'll get a lot of things that are purpose built for these types of applications(PID loops, explicit fault paths, etc), I've seen enough code go sideways without extensive test suites to lean more towards the PLC direction.

I found ladder pretty straightforward and debugging "live" was much easier than the whole compile/build/flash loop.

A language purpose built for this type of application certainly is (and should be) preferred to re-creating the wheel. Unfortunately, in my case, the Automation Direct arduino based is already on my desk and I'm comfortable with it. I could still use the "ProductivityBlocks", but it's still not ladder logic, not sure how close it is.

What I didn't know previously, as you mention, is that with a traditional PLC, you can pull the instructions from the PLC itself, debug, diagnose, that is a nice feature. All without having the original source code... unless you are trying to protect your intellectual property, some special algorithm. Not a concern for this. Live debug is not something I can do with arduino, though, nothing stops me from putting my laptop next to the lathe and diagnose with a serial monitor... but it's only as good as I'd make it and it's certainly not baked in.

I have setup a fully mocked up testing fixture on my desk. Switches, e-stop and LED lights mimicking the logical inputs on VFD. That creates a fast REPL in an environment where failures and finding bugs is safe. I can pull wires, e-stop, cut power to test and find failure points and their resulting outcomes, fix and re-test. Once it's mounted on the lathe, I'll go through similar tests without the motor connected, watching relay lights, then with motor connected but without belt and then with belt and real runs making chips. Hopefully with all these progressions and several iterations (as always with code) by the time I'm at the machine all primary functions work as intended. I'm sure, you'd want to do something similar if programming in PLC ladder logic.

I have also half thought about creating unit tests and a software simulator for my Arduino looping code. I'll have to see what solutions others have come up with regards to simulating and testing the arduino code.

I certainly need to take another swing at ladder logic, see what it's all about.

 

[B2]

I haven't purchased anything but the VFD up to now,

Which VFD did you purchase?

 

[Beantown]

The Yaskawa GA50UB012ABA