AMX for industrial control?
aries
Posts: 27
I'm curious to hear some feedback about the idea of using an AMX controller in more of an industrial control situation. We have a cooling system plant at our facility that consists of various pumps, cooling towers, blower fans, etc. It is all controlled by a PLC with 8 DIOs and 2 AIOs.
I want to make some changes to how this works. Looking into the PLC that controls it, a Honeywell unit, I find that is extremely proprietary and fantastically expensive to obtain the programming software. For those who think AMX is expensive, you've seen nothing yet!
I am tempted to just rip that PLC out and reproduce the programming on an AMX controller. This would also give me the advantage of ability to use AMX's panels, iPad, and other such that is easily integrated with AMX to display system status and allow for control.
I realize this is not a typical application for AMX gear so I am very interested in any feedback on this idea...
I want to make some changes to how this works. Looking into the PLC that controls it, a Honeywell unit, I find that is extremely proprietary and fantastically expensive to obtain the programming software. For those who think AMX is expensive, you've seen nothing yet!
I am tempted to just rip that PLC out and reproduce the programming on an AMX controller. This would also give me the advantage of ability to use AMX's panels, iPad, and other such that is easily integrated with AMX to display system status and allow for control.
I realize this is not a typical application for AMX gear so I am very interested in any feedback on this idea...
0
Comments
I think it would depend on what you are doing. Anything that can be controlled with a relay or strings would be a good candidates like thermostats, pumps, servo/stepper motors etc. You have the 232/422/485 protocols available so there is a lot of stuff you could potentially control. CAD/CAM and other more sophisticated devices would be more difficult but you could use the AMX controller to send G code to devices to run programs. I wrote a Java program that automated the creation of G code to run PMAC controllers in an industrial application so I think if you are clever almost anything is possible. Certainly cheaper than Honeywell, National Instruments and the other industrial controllers. If you need to calculate interpolations on the fly in real time then I doubt an AMX controller would be able to keep up.
Paul
Thanks for the reply. Indeed, this "plant" can be controlled all with contact closures and analog sampling of temperature probes. It is not particularly complex, nothing like interpolation on the fly for CAM devices like your doing!
I think we're going to give it a shot.. just never seen AMX used in such an application. If others here are doing industrial type of stuff like this with AMX it would be very interesting to hear about it.
You probably know all of that already.
edit: jweather makes a very valid point below.
Brag mode off.
Commercial, yes, industrial, no. Show control occasionally, but even that's a bit of a stretch IMHO. Industrial PLCs are built and tested to a much higher reliability standard than AMX equipment, and provide realtime guarantees for response times. If your AMX processor is garbage-collecting its Java VM while you're trying to pulse a relay for EXACTLY 0.5 seconds, you're in trouble. Use the proper tools, not the cheapest tools.
Garbage collection typically is a very low priority process. A pulse would generate an interrupt and execute immediately I would think.
Paul
I had an instance where I was asked to monitor a watchdog and the pulse width was 80 milliseconds. I asked tech support what the input port response time on the NI series is and received the following:
***Looks like the IO ports require at least a 300 millisecond delay in order to be considered change of state. So I don’t think this will work with the 80 millisecond time change that is happening.***
I don’t know what kind of resolution you’re working with or if this comes into play for you but this might be something to keep in mind.
I would think that manufactureres of this type of equipment have liability issues that go far beyond typical 'end user' legal issues and must therefore also get heavily involved in a legal/liability sense. So, they probably only want company approved monitoring/controlling equpment touching their stuff.
I know I made my irrigation guy mad because I bypassed his sprinkler controller by putting in my own AMX relays. I know it won't hurt a thing and has run reliably for over 5 years. But, the guy voided all waranty. I told him that was fine in my case since In own it and know I can be responsible if I break it. I'll also fork over the money to fix it if I do break it.
We're still on a good terms but we also have an "understanding" about it.
I think that's why you don't see a lot of AMX in industrial settings.
I would agree here. From what I've seen in industrial environments, durability and reliability are paramount. There's a reason those Herschman (sp?) switches cost a fortune.
I have worked with some industrial automation controllers, and AMX controllers compare well with many of them. Since AMX supports RS-232/485/422 there isn't much it can't control if you write the drivers yourself. Where companies like DeltaTau and NI excel is they have the drivers. But as far as the tech goes, AMX generally have faster processors, more memory, an easy to use compiler and many other features that are ideal for industrial automation. I wouldn't hesitate to use an AMX controller for many industrial tasks In fact, AMX would be perfect to control other industrial controllers if you needed motion control or other more specialized duties.
Paul
The reason I suspected an issue is from playing around with relays in AMX training courses... I would create these elaborate series of sequences to make the front-panel LED lights turn on and off (with percussive accompaniment thanks to the hefty relays), but I noticed there was frequently a "hitch" in the sequence that wouldn't be there the next time it played through.
So, meet the unbiased stopwatch: A Basic Stamp 2 with a very simple program. While an input pin is high, it increments a counter, then prints it to a 232 port when the pin goes low. While the pin is low, it increments a counter, then prints it when the pin goes high again. This counter is not intended to reflect any particular time unit, but is expected to be consistent. The time taken to print the values is not counted, but again should be consistent.
The AMX program is as simple as it gets: WAIT 10 { ON[dvRELAY, 1] WAIT 5 { OFF[dvRELAY, 1] } } in DEFINE_PROGRAM. That's the only thing in the program (on a NI-3100 in this case). A repeating timeline with a delay of 500ms was also tested with the same results.
The results when everything is stable are consistent: 510-511 ticks on/517-518 ticks off. This means the stamp is counting slightly more than one tick per millisecond. The difference between the "on" and "off" times is the same regardless of their position in the Basic Stamp's code, so it may just be reflecting the difference in reaction time of the physical relay to open or to close.
The fun starts when you open the web interface to the controller. Just going to http://192.168.1.195 results in a sequence that looks like 523/520/514/518/531/500/596/447/511/517. Clicking Manage System looks like 558/467/932/92/512/518/510/593/508. In other words, loading webpages and running Java stuff on the processor can delay a scheduled time event by up to 421 ticks (~0.4 sec). These were all after rebooting the AMX processor and letting it run for 5 minutes to settle.
My favorite, though, was when it hung for over 10 seconds loading a webpage! This had to be a garbage-collection event: 521/13064/48/531/400/511/517 I was not able to reproduce this a second time, unfortunately.
Note that this AMX program wasn't trying to do anything other than click a relay and display a webpage at the same time: it's not parsing RS-232 traffic, scheduling any other timed events, or talking to touchpanels.
So, once again, please do not use AMX for industrial control. These systems are not designed for realtime operations. There are no guarantees about timeliness, response time, or accuracy. You have no control over what is going on at the hardware and task-scheduling level. This is why I get twitchy when industrial control or "frame-accurate timing" is discussed on here.
My next step will be repeating this with an ATMega168 for more precise timing (higher clock speed, compiled C instead of interpreted Basic), but I'm not expecting much difference in the results. Any other suggestions for things to try?
BS2 code for your inspection:
Perhaps try your test using the I/O ports (as outputs) on the AMX rather than the relay. This will avoid the typical "fine timing" issues that relays create. I would expect the relay to have different times for closing vs release, since the relay contact "return spring" will not be applying the same force as the electromagnet. You may also get contact bounce as the relay is turned on. (Not usually visible to the human eye since the bounce is so quick, but your AVR might pick it up.) Using the I/O ports would bypass any physical characteristics of the relays. Remember the I/O-out voltage is different between the 700/900 and the 2100/3100/4100 series. Maybe a solid state relay driven from I/O would be an easy solution.
Oh, I love the Atmel AVRs. I haven't had any spare time in the last few years to keep playing with them, but they are a great micro.
Roger McLean
Swinburne University
If you're looking for more tests it would be interesting to see how the duet side of things goes handling timing. Shoot me a message if you want me to throw together a little module that toggles an IO from that side. Perhaps scarier would be to see the delay in a couple of characters making there way from the RS-232 port into the duet event handler. Again, hit me up for some code to flag it to your Basic stamp / AVR.
Cheers.
Some devices I have had to control simply wouldn't function if there was that much delay, and yet they do, reliably, on fully loaded controllers. No one is claiming a NI 3100 is a hard real time controller, and I wouldn't want one running my car, but for many industrial tasks that require soft real time control its more than adequate since some latency is expected. Of course, it can be programmed in such a way to not work, but that's a different issue.
Generally if you were to use an NI controller in an industrial application, you wouldn't use it directly connected to motors, but to motor controllers, that do their own scheduling according to their hardware spec. Once the program is loaded into the motor controller, it does the rest and the NI simply processes its feedback. What industrial automation scenario were you thinking of that the NI can't do?
Paul
The bottom line is that AMX processors were designed for media control, where millisecond precision isn't required. Timing within a few seconds is within their ability, but not even single-second precision, not by a long shot. When they come out with a multi-threaded processor, you'll have a better chance at it ... but I have to wonder if that is even in the cards. It's just not a requirement for the kind of work they are designed for.
A re-entrant function implies concurrency which you can't have on a single threaded single processor so I don't understand what you mean there.
Sounds like you are blaming the OS for not being able to execute inefficient code. Any processor can be bogged down to fail if the programmer isn't careful. An NI can't control industrial high voltage motors because there are no appropriate connections to do so. But it can control motor control boards with a serial interface just like XP can. Perhaps there is some confusion about the industrial application we are referring to. Industrial can mean a lot of different things.
Paul
Matt,
Your 'Geek' creds just went way up because of that post!
What I mean by a re-entrant function (and maybe I am using the wrong term, all my programming knowledge is from experience, not schooling, so bear with me if I just used the wrong terminology) is one that calls itself as part of it's operation, like your typical shell sort does. In other languages I have used, you could add an idle() statement in there that allows it to free up processor ticks to do other things (like run another pass of mainline before proceeding), but in NetLinx, it just keeps calling itself until it's done, adding it's own code to the stack again and again, and nothing else is given the opportunity to run until all the copies have hit their return statement.
Not at all. In almost any other language (except maybe Basic
DEFINE_FUNCTION INTEGER pow2(INTEGER n){ // returns 2^n if(n==0) return 1; return 2*pow2(n-1); }Obviously, only one instance of this function can be running at once. A re-entrant function as Paul is referring to, I believe, is one that can be called before its operation is finished, that is, have two threads calling the same function at the same time.You could call this function many times from different threads without fear since it uses no global variables. But recursion is so inefficient and uses so much precious memory that I avoid recursion like the plague unless its the only way.
A re-entrant function doesn't need to have finished before it can be called again, it just can't modify shared variables that would affect other calls.
Paul
DEFINE_FUNCTION INTEGER pow2(INTEGER n){ // returns 2^n return 1<<n }Just thought I would pass that along…Recursion is never the only way. Everything you can do with recursion you can do with loops. But often recursion is the simplest way to do things. I have never had a problem with memory that was caused by recursion, not even in NetLinx...
However NetLinx only allows you to recurse 14 times. Than ^$@$&*@...
Try and write a function that prints the nodes in a tree iteratively. The only way to find your way back up the tree is through the call stack, using recursion.
Paul