Design Con 2015
Breaking News
Engineering Investigations

Multi-Platform Integration

Mike Frazier
4/19/2012 09:08 PM EDT

 8 comments   post a comment
NO RATINGS
View Comments: Newest First | Oldest First | Threaded View
Mike_653
User Rank
Rookie
re: Multi-Platform Integration
Mike_653   5/1/2012 12:05:02 PM
NO RATINGS
Yes, I totally agree with all your comments. On reflection of your comments I would like to clarify a few things in the hopes your comments to software engineers are heard. I did slow down the polling rate and has stood the test of time. With that said, I agree with you and have since changed how I choose some components. Let me explain: With the balloon machine the device sending the motion parameters was an operator interface with very limited intelligence. The OIU sends data to the serial ports at a set rate, regardless of changes. The motion controller was fully programmable but the comms are all handled in the background with only the variables exposed in code. Because of these parameters (limitations) when I am using an OUI (dumb interface), I will only use one from the drive manufacturer and not a third party unit. This is simply to try and prevent any unexpected communication anomalies. I am not suggesting for a moment that there is anything wrong with OUI from other manufacturers. Given the right application and enough time to develop it, I wouldn’t hesitate to use them but in my world I typically don’t have the luxury of time. Mike

Ed Baker
User Rank
Rookie
re: Multi-Platform Integration
Ed Baker   5/1/2012 8:29:04 AM
NO RATINGS
It is a false economy to buy a cheapo controller if this is the sort of thing it will do to you. (At least you found your fault quickly - imagine if your comms buffer overflowed once a week and your customer was on the other side of the world; you would inevitably have made a loss on the project with all the remedial work and your reputation would be in tatters. I won't risk that for the sake of a few tens or hundreds of dollars on a cheap knock-off controller. I accept that your choice of equipment is sometimes limited and that even large manufacturers might have bugs in their kit. It is my hope that software engineers reading this will realise that such a simple bug in their code for circumstances which "will never happen" (ahem) could, in the real world, cause a major problem; on a bench in a lab comms failure is annoying. In a steel mill or a printing press with hundreds of tons of moving metal things don't go "click" they go "Bang" and people can get hurt.

Ed Baker
User Rank
Rookie
re: Multi-Platform Integration
Ed Baker   5/1/2012 8:28:54 AM
NO RATINGS
Regarding your comment about motion controllers' sole job being to control motion, I almost agree. However, we all know that you have to know what position to be at, which usually / sometimes involves comms so if your comms fails your motion controller fails. I have designed products in which I even allow for a limited error concealment in comms messages so if a single message is lost due to noise (for example) the machine can be configured to make a "best guess", raise an alert so that the user program can take whatever action is required on that system. Of course, it won't do so indefinitely and there comes a point when it has to raise an error. This is available behaviour, not default behaviour and the decisions are left to the implementer, but crucially the information is given to the user by means of warnings / trips and NOT just thrown away and ignored. And buffer overflow is strongly defended against by both software and hardware where available. Incidentally, if the comms buffer did overflow who is to say that the next RAM locations won't contain the speed demand or some other state machine state. Or a user variable which controls some digital outputs which extend or retract a sensor or arm into the works of the machine? A data error could destroy the machine and therefore project timescales and potentially the whole project. Sounds like a catastrophe waiting to happen for the sake of a bounds check on the receive buffer.

Ed Baker
User Rank
Rookie
re: Multi-Platform Integration
Ed Baker   5/1/2012 8:28:16 AM
NO RATINGS
My comment was not apportioning blame; I was pointing out how if errors are handled PROPERLY when they are first known about then finding the real cause of a problem is so much easier. If your drive (or PLC or whatever it was) raised an alarm state then you would have "solved" the problem much more easily and quickly. (Quotation mark used because is the problem really solved, or just worked around? Could it ever recur of somebody plugs another comms cable into the system?) This needed pointing out because a comms device which can overrun its own buffer is hideously bad. That's a COMMS101 type of error (if it's quite as described / interpreted) and would make me strongly reconsider whether the vendor really knows what they are doing.

Mike_653
User Rank
Rookie
re: Multi-Platform Integration
Mike_653   4/30/2012 4:41:02 PM
NO RATINGS
I did the programming for another company on a project where I had to passing encoder positions over serial Modbus at a fairly fast rate. Everything worked as I expected until the speed increased. At somewhere around 4 inches a second, things started screwing up. I would have expected an ever increasing latency of position values but instead all the data just disappeared. The motion took precedence over the communications and being a less the full featured controller the position, there was no place to store the data. It was just lost. At times I get to pick components and other times the customer specifies them. I don’t know if this speaks to a more rapidly changing market or the number of years I have been in the business, but more and more I find myself changing controllers due to end of life of a product. All these factors make it very hard to avoid all the pitfalls and many times force a work around.

Mike_653
User Rank
Rookie
re: Multi-Platform Integration
Mike_653   4/30/2012 4:40:37 PM
NO RATINGS
I would agree your point is valid and in theory absolutely right. Reality as usually tends to be more shades of gray then the black and white answers we all hope and search for. You could blame me for poor component selection, the hardware manufacturer for poor firmware routines or maybe even certain organizations for not defining or adopting more universal standards. In the automation world we are saddled with the task of specifying components, designing parts and then given 12 – 20 weeks to make it all happen. Most of the machines we build are a “one off”. The balloon machines are somewhat different as we’ve built quite a few of them but even those, give the span of time they were built over, have had 3 major controls changes / upgrades. None of this is an attempt to excuse poorly picked components or sloppy software but it does end up being a reality that we face on a daily basis. A lot of times we only get a week or two of equipment up time before shipping. One thing I will say with regards to motion controllers and anomalies such as this one. A motion controller has one main job and that is to control motion, everything else comes second. I hesitated saying those words because I am sure I will never hear the end of comments fueled by them. I have experienced anomalies more than a couple of times over the last 30 years. I routinely contact the manufacturers in those cases but seldom get satisfactory answers with regards to time slicing and priorities other the management of the motion itself. Everyone can tell you about their “servo loop”!!

Ed Baker
User Rank
Rookie
re: Multi-Platform Integration
Ed Baker   4/23/2012 11:48:37 AM
NO RATINGS
Sounds to me like the receiver was faulty - should it have been able to overflow its own buffer? Surely it should have rejected the message and not corrupted data beyond the end of its own receive array. What you were seeing was arguably (if I have understood the problem correctly) a secondary fault. The receive handling was actually at fault. If that had returned a NAK or something it's likely the display would have detected it and stood a fighting chance of reporting the error to the next layer up. (Perhaps the user.) This seems to me like a classic wild goose chase with a workaround; if the various compnents of the system had been designed with a more defensive mindset I bet this would not have taken nearly as much time to detect.

agk
User Rank
Rookie
re: Multi-Platform Integration
agk   4/23/2012 10:45:47 AM
NO RATINGS
A practical approach to analyze and solve erratic running of the servo.At this situation because of proper analysis , it was solved by rewriting the program. Many times the noise or interference or poor supply filtering or regulation causes this kind of erratic operations. Mostly it is difficult to solve these issues without degrading the performance of the system.

Radio
LATEST ARCHIVED BROADCAST
EE Times Senior Technical Editor Martin Rowe will interview EMC engineer Kenneth Wyatt.
Top Comments of the Week
Like Us on Facebook

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
EE Times on Twitter
EE Times Twitter Feed
Flash Poll