The Logo device from Siemens was another attempt. We thought they were kinda cool, but I don't think they had much of an impact in the marketplace.

There are many examples of the programmable (Smart Relay' (Re-lableled) They are useful for the odd small low count I/O where a full blown PLC is overkill.
Max.

 

The Logo device from Siemens was another attempt. We thought they were kinda cool, but I don't think they had much of an impact in the marketplace.

https://www.automation24.com/logic-...MIhfTP1vef5gIVyrzACh0kSwRyEAQYASABEgLXivD_BwE

I don't how we quantify an "impact in the marketplace," but my gut reaction is one of disagreement with your statement. The Siemens Logo and similar competing "Micro brick"/"Smart relay" products are probably never going to surpass full-functioning PLC sales, but I don't think they were intended to. They fill a rather large nice that I'm surprised took so long to accommodate. For machines whose complexity is such that it does not demand an actual PLC and all the advanced functions that go along with it (floating point math, scaling, comms, string manipulation, remote I/O, etc.), but does actually require a bit of logic, enough so that a panel full of relays would become large, tedious, and costly, the programmable relay is ideally suited.

I have used them for numerous projects:
Adding reverse operation function (swap DC field polarity) to an older machine, with a few new safety interlocks (at zero speed, machine not in auto, et. al. I can't remember)
Adding automatic QA/QC functions to simple rewinder
Optimizing hydraulic power units for power savings (shutdown when left on but not in use, after x minutes),
many more, no real point in listing all of them.

I don't even use them frequently enough, actually. If you really analyze the cost/benefit it probably makes sense to use them any time a solution demands more than 2 logic relays, and any time even a single timer or counter is needed. Consider this programmable relay for $69, vs this common timer relay for $62.50 ($55 + $7.50 base). Consider that time is money, and running wires takes time. Depending on how much your time costs, and other factors such as production volume, using a programmable relay might make sense even for the smallest of jobs that almost anyone would initially assume don't need more than a couple relays, especially if that lets you decrease the size of the panel.

EDIT: Damn. I see Max beat me to it days ago and said it in fewer words that people are more likely to read.

 

I agree that the logo adds flexibility. I always recommend a path to the future however, and feel that a remote I/O on comm provides even more flexibility. I like to change them out whenever possible and I/O back to a PLC platform.

 

I agree that the logo adds flexibility. I always recommend a path to the future however, and feel that a remote I/O on comm provides even more flexibility. I like to change them out whenever possible and I/O back to a PLC platform.

Sure, when you're talking about a machine that's part of a line that has a PLC. Like for example an extruder as part of an extrusion line, comprised of winders, capstans, measurement devices, etc. Each of these machines could have a remote I/O and be controlled by a single line PLC. But if the machine is to be used as a standalone device like a portable HPU or such, then the smart relay keeps the logic on the machine and needs no overlord.

Or am I missing the point? I feel like I might be misunderstanding you.

Assuming we are on the same page, the best of both worlds is probably a smart relay like the one I linked to previously, which has Modbus functionality, so therefore could be setup with a Local/Remote switch and used in either scenario; standalone, or as part of a line. In remote mode it would be a Modbus slave and effectively turns the smart relay into remote I/O.

 

PLC are nothing but microcontrollers in disguise. They use ladder logic (a GUI interface that converts the coding to machine language). Writing in C to microcontroller is a more clear way of getting the response you want and the complier takes the C and converts it to machine language. I built a food processing conveyor system using two Arduino's, stepper motors, Automation Direct stepper controllers, and power supply for about $800 dollars. I have used Rockwell, GE, Opto 22, and Siemens and program in both ladder logic and C. Using the microcontroller was way more fun and quite a bit less expensive. If I had installed Compact Logix, for example, the amount spent would be over $30,000 and $5000 for a year's license. Using programs like Node Red to interface microcontrollers will give you one of the most powerful platforms available. Node Red can be used for a HMI touchscreen and has IBM Watson as the back end. Wago and Ignition HMI have made recent moves toward interfacing this platform.

 

Sure, when you're talking about a machine that's part of a line that has a PLC. Like for example an extruder as part of an extrusion line, comprised of winders, capstans, measurement devices, etc. Each of these machines could have a remote I/O and be controlled by a single line PLC. But if the machine is to be used as a standalone device like a portable HPU or such, then the smart relay keeps the logic on the machine and needs no overlord.

Or am I missing the point? I feel like I might be misunderstanding you.

Assuming we are on the same page, the best of both worlds is probably a smart relay like the one I linked to previously, which has Modbus functionality, so therefore could be setup with a Local/Remote switch and used in either scenario; standalone, or as part of a line. In remote mode it would be a Modbus slave and effectively turns the smart relay into remote I/O.

I’m thinking baggage handling for some reason.

 

I never said they had disappeared, only that I was not aware of them having much of an impact. That might be a function of the circles I traveled in rather than anything else.

 

Years ago, we built a vision system with the Harris RTX2000 FORTH chip, used to sort half peaches in a cannery. We even made our own cameras. This drove our own designed I/O boards for shaft encoder input and kicker driving to eject the peaches to the appropriate belt. All this was custom hardware, and programmed in FORTH.
Later, the RTX2000 board and camera were replaced with a Linux box with video capture card and a commercial camera. All off the shelf parts.
The RTX2000 was a magic chip. It could sort the fruit quite well, and it ran at only 20Mhz.

One of our success...


Our UNIMOD series of boards did just that. They were marketed as "Wiring Eliminators". Used for building management, and they are still going strong after 30+ years. The main failures are electrolytic caps drying out. These boards has 16 I/O each, and allowed the interconnects between floors in multi story buildings to be run in fire proof network cable, not great multi core runs like it used to be, that having all the switch and contactor cables run to the basement. This saved a heaps of money.
View attachment 193839
This is the UMDC, the "slave" part. Many of these can be on the network.

Then, the UMH or host. This had the wiring matris stored in flash memory and that could be easily altered as required.
View attachment 193839


But we did put a fair bit of work into making the I/Os pretty tough. An had good protection on the power supplies. Custom hardware can work, but a big problem is support in the long term.
I am retired now, sort off, and will finish my last 6 x Super Unimod boards (SUM) for a customer so he can have spares. After that, no more.

EDIT: The SUM boards also can run on the network, and have 8 x inputs, 8 x relay outputs and 4 x Analog inputs.

There is a lot to be said for PLCs and ladder logic (I have never used it myself) in that when the hardware dies, a replacement can be found, even from another brand, and the program grown into it fairly easily.
The room for custom hardware still exists, but you do need to make it as bulletproof as you can. Industrial environments can be pretty harsh.
But trying to replace an existing working solution with your own custom version is not the way to go. Look for something that does not work well and try to fix that.
As an example, we did a custom Mag Flow water meter for irrigation, the Irriflow...
View attachment 193835

And earlier, the M300 for industrial applications..
View attachment 193836
Both these filled a need in the market. And PLCs could no do this.
So, look for something that neesd a fix, not one that is working well.

Curious, Forth, why did you use it, why was it chosen ?

Regards, Dana.

 

I never said they had disappeared, only that I was not aware of them having much of an impact. That might be a function of the circles I traveled in rather than anything else.

In similar fashion, I recently worked for a client that had them sprinkled all over, while another client was trying to sell me boxes of units they had pulled out. Scooped a commission when I connected the two parties together.

 

Curious, Forth, why did you use it, why was it chosen ?

Regards, Dana.

I think FORTH was chosen because each word can be run immediately without having to compile the whole lot. That makes it really handy for debugging and testing.
Mine was the hardware side. I could write a little FORTH, enough to test the hardware, like wink an LED. Then my boss would put the magic in, and make it dance
Here are some pictures. This later production version does not have out own camera, but uses a commercial camera read by our frame grabber.


The CHRIS (Colour High Resolution Imaging System) board. Just as an aside, "Chris" is my wife's name. I got a few points for that



This is the Aux board that read the shaft encoder and drove the kickers. It too was programmed in FORTH.

The "Brain"..


All these boards are 1994 or earlier vintage.

I know this is off the subject of the original question, but I thought it may be of interest.

For those not knowing FORTH, a good book is "Starting Forth" by Leo Brodie.

 

If you at a future time still want to do a design from scratch consider
using a PSOC.

32 bit ARM + 20 bit DelSig + 12 bit SAR + DAC (I & V) + Vref + OpAmps + Analog
Muxes + DSP +....all on one chip. Attached is a component catalog. A component is an onchip
resource. Catalog shows a "typical" PSOC 5LP.

A low end project example (PSOC 4) shown here -

https://program-plc.blogspot.com/2015/02/build-very-cheap-plc-using-programmable.html

IDE (PSOC Creator) and compiler free, good starting board is $ 10 for PSOC 5LP baord.


Regards, Dana.

 

If you take a careful look at the Red Lion, Siemens, and other manufacturer's products you will find that many PLCs have alternate programming language support, rather than only Relay Ladder Logic.
A baggage handling system would expose not only trained maintenance personnel but the general public to some level of risk due to failures of the control system.
I would strongly advise against your planned adventure, but doing a maker project that simulates a baggage handling system for your own use might be rewarding.

 

There are companies selling IoT based industrial controls. They have support available and the cost of parts is more than a just reason to get away from the big boy PLC's. As an example, if you look at Wago they have adopted IoT platforms that work alongside their hardware and allow programming that is not Ladder Logic. Node Red also interfaces easily with Wago. Are the big boys scared? I would say so given the fact that they have raped the market price-wise and see the inroads happening with more and more buyers selecting the IoT direction. Just like the compact disc player of yesterday if you don't stay ahead of the curve, a flash drive or streaming internet will see you in the rearview mirror. The PLC of today is the compact player of yesterday unless you see that you must be like Wago.

 

It seems some have missed the WHOLE point of of the original intention that GM instigated and that Dick Morley came up with, that is a system that allows shop floor maintenance personnel to use a tool that replaces the old relay logic panels and replace them with a system that uses the same form of documentation, i.e.replace ladder logic schematics with a similar form, not only displayed on a PC screen in the same format, but show which logic functions are ON/OFF etc.
When a manufacturing system assembly lines are made up of individual electronic/CNC cells it is imperative to solve any malfunctions ASAP in order that the whole process is not brought to a halt!
Max.

 

Hi Max,
Have you checked out Node Red? I built an industrial food packaging line using this platform with a Groov box so that I could use it with a touchscreen HMI. This gave the production personnel complete control over the production line. They were able to change recipes as the packaging line changed products. The motor controls were controlled by microcontrollers with a serial interface from the Groov box.

 

Hi Max,
Have you checked out Node Red? I built an industrial food packaging line using this platform with a Groov box so that I could use it with a touchscreen HMI. This gave the production personnel complete control over the production line. They were able to change recipes as the packaging line changed products. The motor controls were controlled by microcontrollers with a serial interface from the Groov box.

Hey Rob,
Sounds like a neat implementation. It's been interesting watching Opto22 promoting NodeRed in their YouTube videos. I think several others in this forum have tried to point out that the ability of the maintenance staff in many production facilities may not include troubleshooting skills in Node.js or C++, and that is a factor in why the more traditional control platforms still command a fair amount of the newly installed base of control systems in plants. I recall Triangle having microcontrollers in their baggers a good number of years ago, but being forced to offer the option of one of the major PLC manufacturer's controllers and HMI panels to customers because of the skill sets and training of their customer's plant floor maintenance personnel. Some of the refrigeration compressor folks, like M&M, have face similar situations as well. As time goes on, skill sets may increase in the general workforce (due, in no small part, to STEM education advancing in schools down to even the elementary school level) , making RLL and the "fixem' with a hammer and screwdriver" controllers less valuable to those planning new control platforms, but I think we are still a ways off from obsoleting the traditional PLC simply due to installed cost. I am, however, hedging the bet by getting up to speed with technologies like MQTT messaging and LoRa wireless with the expectation that these will find their way onto the plant floor as time goes on.

 

Hi dw,
I have programmed touchscreens HMI's for Allen Bradley, GE, and Siemens. The best platform I have encountered is the Groov Box (and now they have a new PLC platform too). The Groov Box made it so easy to program. The production manager wanted a text and email to his cell phone when the production line stopped. It took less than 30 seconds to program this transaction. I was amazed by how fast it was to make this happen. Plus it will work with most touchscreens. Even more cool is that writing this function to a full-size screen also wrote the program for a smartphone or tablet without any additional input.

 

Hi dw,
I have programmed touchscreens HMI's for Allen Bradley, GE, and Siemens. The best platform I have encountered is the Groov Box (and now they have a new PLC platform too). The Groov Box made it so easy to program. The production manager wanted a text and email to his cell phone when the production line stopped. It took less than 30 seconds to program this transaction. I was amazed by how fast it was to make this happen. Plus it will work with most touchscreens. Even more cool is that writing this function to a full-size screen also wrote the program for a smartphone or tablet without any additional input.

Good Morning Rob,
I enjoy those advantages of Node Red on my home automation system as well. Since I don't have to worry about others being familiar with a Node.js platform for programming and troubleshooting in order to keep my home going, it's an elegant solution.
I recall a new employee at one of the major packaged salad plants convincing the maintenance supervisor that he could save a ton of dough by not paying all those nasty software license fees and high PLC hardware prices if he were to put in some earlier Opto22 platform devices interconnected with inexpensive RS485 serial links. Engineering didn't catch on until the lad had moved on to another company and a controls engineer got a panic call at 2 AM when the plant shut down because the water system quit working. Since the manager had also moved on, so no one knew the nooks and crannys where the money saving equipment was installed. It only took the company 5 years to locate and replace all the controls programed in Basic with PLCs the maintenance employees had been (and were continuing being) trained on. Like you, I've programmed a variety of PLCs and EOI products. I recall seeing the multiple pages of lines of code it took to program as single PID loop in an early Allen Bradley product in the 1980s, and wanting to jump in an try to figure out how to add an assembly language module to the firmware on the processor (the PLC2/30 was a Z80 family processor based product), but got a dose of reality when I was asked who else in the oil patch could figure out how to change the loop parameters in a control panel away from the test bench (assuming my skills with an programmer and debugger would get me through the task). Thankfully, the RLL instruction set evolved to add single blocks of code for this and other operations such as math and file manipulation. The big rush to embrace ST and SFC programming in later years was a great help for integrators and plant engineers in crafting simple solutions in system programming and commissioning, but the decision to utilize these tools had to include the on-going cost of 24x7 staffing in facilities that utilized them (on-site or via contract) where the operation couldn't wait for someone to return to the plant. I've witnessed the opposite side of all this as well, when a machine builder was offered an extremely lucrative contract to furnish their specialized equipment to a customer in an on going basis. Only proviso was that they had to replace the microcontroller with a small PLC, since the customer was used to validation and maintenance of assets that used this type of platform. I found myself in front of a group of C programmers with deer in the headlights expressions on their faces (the near term success of the company literally balanced on getting this contract). Rather than debate the reasons they should gain a new skill set in a odd programming platform, I fired up a Logix programming package, and introduced them to the IDE, Library of Tools, and file structures in the package, with the ease of on-line debugging and programming changes. The engineering staff walked out of the meeting satisfied that this really wasn't that difficult to deal with. The value of the contract was more than sufficient to absorb the higher hardware cost and learning curve for the engineers at the OEM. Later our firm's the account manager that accompanied me on the sales call asked me what the hell all those strange words were I used in the presentation. My point...perception of "easy or hard" has a lot to do with "comfortability" due to past experience and successes. Cheers from a Baby Boomer perspective.... David

 

I recall seeing the multiple pages of lines of code it took to program as single PID loop in an early Allen Bradley product in the 1980s,
Cheers from a Baby Boomer perspective.... David

Actually the first CNC project I did was using the AB 1771 PLC's in the 80's and they had just introduced their 1771-QC (bulletin 1388) servo positioning module. No writing of PID loops etc.
PLC's generally have not been used for CNC due to lack of interpolation for multi-axis.
Fortunately this was a single axis application.
I eventually went with Mitsubishi for both PLC and CNC, (the software was free!).

BTW, I guess Baby Boomers have something against paragraphs!?
Very hard to read.
Max.

 

I know I'm not really qualified to comment on this in ways, but having played with microcontrollers for the last seven years, hobby level computer programming for at least 15 years, and having the opportunity to look at old ladder logic printouts and information I could find laying around when I worked in a factory I have to say stick with PLCs.

If you want to do it as a learning experience go for it. If you want to do it for industrial purposes you will probably have a hard time selling it. I would be more willing to pay the extra expense of the PLC that I know I could put someone on it their first time and they could at least understand to some extent what is happening. A totally new troubleshooting process for a custom embedded system will probably cost more in down time, training, and lost business to justify the savings. Even if it runs flawlessly for 10 years the first time it goes bonkers you will regret it.

** Edit

Along with troubleshooting you also have to account for how changes to the system will be made. PLCs and ladder logic would allow anyone to easily add or delete actuators and sensors for push cylinders, motor brakes, and whatever when changes need made to the setup. Would you have to have someone come out and reprogram the embedded system, or would you have to train someone to do it along with having enough down time for them to work out the details until they get to know the system? Either way adds costs.

It would be kind of fun to do with a microcontroller, but I think if you don't at least include ladder logic in the package and model it after a PLC it will be hard to sell.