That's not what I'm reading. Programs lost due to dead battery or firmware password protected or convoluted logic that no-one can decipher or can't locate the programming software and later versions aren't compatible. Programming license problems.
I don't know what the number is today but in 1990, if the Mini Van line went down at General Motors, they were talking a million bucks/hour. They kept reminding me because I used a PC clone motherboard from Taiwan for the CNC
Big war with GM engineers so I grabbed one of their office PCs, transferred the controller cards to this desktop machine that was perched on a chair, loaded the software and the machine ran.
I requested that they demonstrate similar with one of their PLCs, you know, those things that you aren't allowed to keep in stock.
Yeah, people as asses if they want to be. A password on a PLC defeats the purpose of a PLC, IMHO, but obviously that's what some idiots will do. People stick fragile dongles on PCs too. And of course no access to source code either. These days likely requires full time Internet access for the software to regularly "phone home." They can't help but look for the money stream through a lock-in of some sort.
My current boss has a reliable consumable lock-in already but he still can't stop thinking about the software as a means to control the customers anyway.
I don't want to argue about what type of signal interface or control method is best. Everybody has his own preferences and that depend on customers requirements, budget and also historical reasons. Fortunatelly, the Propeller is very flexible and we can implement any of them like we choose.
Theoretically, EtherCAT would be "best" and could cover all of them (torque mode, velocity mode with external feedback and direct position control). But I've abandonned that because it was too complex for me. I simply couldn't get it work in half a year. Maybe, now that AI is getting better at coding I'd start a new try sometime in the near future... But for now I stick to what's available at reasonable cost and is easiest to implement for me.
BTW, I do have plans for implementing closed loop control. The second RJ45 socket in the picture of post #11 was originally meant for a single encoder input to implement thread cutting on a lathe without a servo drive on the main spinlde but only a VFD with induction motor. But I've already designed a PCB that can be connected to this input and serves as an "encoder expander". It can take the signals from up to six encoders or glass scales, count the pulses and send the position counter values over a serial protocol to the main controller. I can simply re-program the 3 smart pins that handle the ABZ signals of the single encoder input, there.
@ManAtWork said:
I don't want to argue about what type of signal interface or control method is best. Everybody has his own preferences and that depend on customers requirements, budget and also historical reasons. Fortunatelly, the Propeller is very flexible and we can implement any of them like we choose.
Theoretically, EtherCAT would be "best" and could cover all of them (torque mode, velocity mode with external feedback and direct position control). But I've abandonned that because it was too complex for me. I simply couldn't get it work in half a year. Maybe, now that AI is getting better at coding I'd start a new try sometime in the near future... But for now I stick to what's available at reasonable cost and is easiest to implement for me.
BTW, I do have plans for implementing closed loop control. The second RJ45 socket in the picture of post #11 was originally meant for a single encoder input to implement thread cutting on a lathe without a servo drive on the main spinlde but only a VFD with induction motor. But I've already designed a PCB that can be connected to this input and serves as an "encoder expander". It can take the signals from up to six encoders or glass scales, count the pulses and send the position counter values over a serial protocol to the main controller. I can simply re-program the 3 smart pins that handle the ABZ signals of the single encoder input, there.
Just letting you know that at least a couple of us are paying attention to your developments. We have too few motion guys here
I am excited about these low cost VFDs. The ones that I am using are switchable between VFD/FOC.
Fitted one to a Bridgeport knee mill.... beautiful. The motor is smooth and the variable speed means we never need to change pulleys.
For what these things cost, toss the star/delta contactors and replace them with these VFDs. So many hydraulic machines are left running full time and their duty cycle can be 10%. Constant start/stop is a PITA but what if they could gently spin-up and spin-down in between and therefore only run when needed for actual work. Opportunities abound.
Comments
That's not what I'm reading. Programs lost due to dead battery or firmware password protected or convoluted logic that no-one can decipher or can't locate the programming software and later versions aren't compatible. Programming license problems.
I don't know what the number is today but in 1990, if the Mini Van line went down at General Motors, they were talking a million bucks/hour. They kept reminding me because I used a PC clone motherboard from Taiwan for the CNC
Big war with GM engineers so I grabbed one of their office PCs, transferred the controller cards to this desktop machine that was perched on a chair, loaded the software and the machine ran.
I requested that they demonstrate similar with one of their PLCs, you know, those things that you aren't allowed to keep in stock.
This is where the BS stops
Yeah, people as asses if they want to be. A password on a PLC defeats the purpose of a PLC, IMHO, but obviously that's what some idiots will do. People stick fragile dongles on PCs too. And of course no access to source code either. These days likely requires full time Internet access for the software to regularly "phone home." They can't help but look for the money stream through a lock-in of some sort.
My current boss has a reliable consumable lock-in already but he still can't stop thinking about the software as a means to control the customers anyway.
I don't want to argue about what type of signal interface or control method is best. Everybody has his own preferences and that depend on customers requirements, budget and also historical reasons. Fortunatelly, the Propeller is very flexible and we can implement any of them like we choose.
Theoretically, EtherCAT would be "best" and could cover all of them (torque mode, velocity mode with external feedback and direct position control). But I've abandonned that because it was too complex for me. I simply couldn't get it work in half a year. Maybe, now that AI is getting better at coding I'd start a new try sometime in the near future... But for now I stick to what's available at reasonable cost and is easiest to implement for me.
BTW, I do have plans for implementing closed loop control. The second RJ45 socket in the picture of post #11 was originally meant for a single encoder input to implement thread cutting on a lathe without a servo drive on the main spinlde but only a VFD with induction motor. But I've already designed a PCB that can be connected to this input and serves as an "encoder expander". It can take the signals from up to six encoders or glass scales, count the pulses and send the position counter values over a serial protocol to the main controller. I can simply re-program the 3 smart pins that handle the ABZ signals of the single encoder input, there.
Just letting you know that at least a couple of us are paying attention to your developments. We have too few motion guys here
I am excited about these low cost VFDs. The ones that I am using are switchable between VFD/FOC.
Fitted one to a Bridgeport knee mill.... beautiful. The motor is smooth and the variable speed means we never need to change pulleys.
For what these things cost, toss the star/delta contactors and replace them with these VFDs. So many hydraulic machines are left running full time and their duty cycle can be 10%. Constant start/stop is a PITA but what if they could gently spin-up and spin-down in between and therefore only run when needed for actual work. Opportunities abound.