Machine Simulation Feedback

Hello all! I have been playing around with talking to a plc via a communication driver and Visual Basic. So far I have just used this to get and store some data to a database. I was wondering if I could use it to simulate a machine in order to test my code when developing a project. Basically it would replace my switches and lights rigged on my desk to test code. If I used Visual Basic I could make much more flexible simulations, such as making an object on the screen move if a certain output on the plc is on and using custom button controls to simulate inputs. Hell , I could even set an input if the moving object on the screen passes another point on the screen to see the effect of my plc program. Would this be too much work or am I just having a cool dream. Thanks.

Simulators can be pretty interesting.

Sometimes they make you feel like you're a great programmer. Sometimes they make you feel like an idiot. I prefer the ones that make me feel like an idiot.

The problem with a lot of simulators is that they are designed to mimick the perfect-world. That is, "It should go like this."

If the world was fair and you were a good boy, then maybe things would "...go like this". The world ain't fair... and I'll bet my house you haven't always been good!

A simulator serves two purposes:
Purpose #1: "What happens if the process works right?"
Purpose #2: "What happens if the process works wrong?"


BEGIN RANT:

FAR TOO MANY Programmers are satisfied with using the simulator for Purpose #1. I call that "minimalist engineering", that is, they are satisfied with "Good Enough!" - one of the most hateful concepts in engineering, or, human experience, for that matter! That's almost as bad as "If it ain't broke, don't fix it!"

With respect to "Good Enough", I tell my guys... "If you find yourself saying "Good Enough", then slam on the brakes, back-up, and find out where the hell you lost control of this design process! Then, pick-up from there, again, keeping the intended goal in mind."

"Good Enough", even "Good Enough for Government Work", ain't so good. "Good Enough" killed those people on the Challenger. I don't buy, "Good Enough". You shouldn't either.

With respect to "If it ain't broke, don't fix it!", the idea there is, "That's the way it's always been! It worked then, it'll work now." (Ron, this ain't an attack on you... only on the concept.)

Most of the processes currently being used in the international industrial complex are based on very old ideas or, at least, old technologies. Even those systems that have newer technologies incorporated in them still contain some older solutions.

I say, quoting Tom Peters, "If it ain't broke, break it!" Everything can be made better, if a good mind and a later (if not latest) technology is applied. The name of the game, in these days, is efficiency! The older "slam-bang" methods are losing time and money!

In a lot of cases, it's simply a matter of looking to see how things are done. I've run into a lot of cases where things are done in a manner that might have been good in their day, but today, they are seen to be incredibly STUPID, INEFFICIENT and COSTLY !!!

So, if you have an idea that you know can improve on a particular process, BREAK THAT DAMNED PROCESS! Just so you have to fix it - better!

END RANT:

Simulators need to be designed to handle the "What if..." situation. That is, don't design a simulator to verify correct operation alone. Design a simulator that will identify those "damn-its". Then use the simulator to help figure out a way to handle the "damn-its".

Regarding the Rant

Terry : I agree! But you left something out -- politics.

Currently, my mechanical counterpart and I are expected to build a new machine, for which two functioning models are already on the floor. These were built by Steve, the boss whom I so revere, an at the time were cutting edge technology.

Now the problem - the capacity of the motor drives on these puppies are maxed out. One even has a fan blowing on the motor, trying to cool it. There are some mechanical issues as well, which Steve addressed, but left some deficiencies, again due to the limits of the technology.

We are expected to build a third machine now. Our problem is this: If we duplicate the original design, we are all but guaranteed a working machine, albiet with all the same bugs in it.

However, if we change ANYTHING to try and improve the mechanism, and it runs over-time or over-budget, we are faced with that most difficult-to-answer question, "Why didn't you make it like the others?"

Personally, I favor the conservative approach, because there is one adage (n., boned wisdom for weak teeth) that you did not address :

Slavotsky's Law #1 : Thou Shalt Always Cover Thy ***

Just my two bits...

Timothy: I been there, too, and I agree that occasionally there just isn't a "real-world" way to "make it better" especially when minds are closed in advance. But you gotta try.

The only chance I can see to fix things in the environment you describe is to put on your best "Salesman" hat and sell the improvements before you start. Usually, if you can demonstrate a cost savings and sell your proposed improvements in advance, you stand a much better chance of not getting caught in the "why-didn't-you-build-it-like-the-others" trap. If I hear you right, it sounds like there are other people who are ultimately responsible for the overall design of these machines and they are the ones who need to sign off on any changes. This has got to be done in advance.

I hate to have to "sell" my proposed improvements as much as the next guy, but you gotta do it if you want to be the one to make things better. And if you don't want that, you don't really belong in this field anyway.

Learn to sell. Learn to talk the financial language. Get the Accounting Department on your side. In short, get out of the Engineering box. It ain't fun for us techy types but its necessary.

Re: Regarding the Rant

TimothyMoulder said:

We are expected to build a third machine now. Our problem is this: If we duplicate the original design, we are all but guaranteed a working machine, albiet with all the same bugs in it.

However, if we change ANYTHING to try and improve the mechanism, and it runs over-time or over-budget, we are faced with that most difficult-to-answer question, "Why didn't you make it like the others?"

Click to expand...

That's an easy one... Give the customer this info, and let THEM decide!...

beerchug

-Eric

Z-man:

A couple of things to consider when creating a simulator:

1) You are currently reading/writing to the "regular" memory registers in the PLC. If ou write a value to a register, and the PLC program also writes to the same register, your data will get overwriten by the PLC logic execution, right? In your simulator, you will be writing to the I/O image table. The inputs will get overwriten by the PLC every scan, unless you somehow disable the PLCs ability to scan the modules. Some can, some can't disable I/O scanning. The only way around this for those that can't is to map all the inputs to internal registers, use ONLY the internal registers in your program, and disable the mapping when doing your simulation.

2) There are commercially available simulators on the market. While I approve of you making your own, you might want to look at them as an alternative to your time (=your employer's money). They may (or may not) be more cost effective.

3) As Terry mentioned, you will probably wind up simulating an ideal world. You'll find out more about your program if you add to your simulation the non-ideal conditions as well. For each output, add a "It's broken" button or checkbox, so that the correct feedback ISN'T set, or that the feedback is active when the output isn't. If it's a conveyor project and your simulating photoeyes, have the photoeye able (not the default - just give it the ability) to NOT see an object (simulating an item removed from the line, or a jam, or a defective eye) at the expected interval. That's when you really see how good your program is.

The cool thing about simulation with a good graphic interface, is that the customer forgets that they are looking at a simulation, and starts comments (i.e. changes) based on what they see. The downside is, you when you debug, you have to determine if its a problem with your logic, or with your simulation.

Remember, you can only simulate the known. You can't simulate the unknown. Nature will still throuw you curves. But a good simulation can save hours of field time (See Steve's remarks in another thread about plane code.)

Thanks Allen. Yes I would use internal bits in my testing instead of the actual Input table. This was the kind of feedback I was looking for. I think that if it was a pretty simple project that building a simulation to test certain conditions might be worth the time, but if it came to a larger program just writing the VB simulation might take more time than it is worth. Thanks for the feedback.

One more thing Allen, if I did use the input table instead of internal bits could I do a Communications refresh instruction in my ladder program.Since the inputs are scanned at the beginning of a plc cycle the com refresh should overwrite the input table. I use AB and AutomationDirect PLC's. I could probably look it up but would also like to see if anyone has tried it.

It might be just as easy to write your simulation as a subroutine of the PLC. Some PLCs will allow you to do something like this:

 Output    _______                Input

--| |-----| Timer |----------------( )-

          |       |

          |_______|

x


Output could be a solenoid and input could be the corresponding end-of-travel switch for the actuator controlled by the solenoid. Not all PLCs will let you attach input addresses to coil instructions. If that's the case for the model you're using, you'll need to use internals. If your model won't let you use input addresses with coil instructions, it might let you MOVE or COPY internals to inputs at the beginning of the program scan.

As to your question about doing a communications refresh at the beginning of the program scan. You'll need to check what the communications refresh actually does. If it just reads the serial port buffer, can you be sure that there will be valid data available? If not, will the refresh function leave the input table alone or will it write all zeros to it? Also, will the refresh function run to completion before the ladder logic execution proceeds to the next rung of logic?

Keeping it Simple

On the same track, If It Ain't Broke applies equally to methods as well as materials.

For instance, the machine I'm working on right now could have been done via PLC, but somebody somewhere got a hard-on for VLC and Devicenet.

Tomorrow, we will be calling in a ringer from the Devicenet manufacturer to tell us why the frick our machine is so bloody vulnerable to noise, while the identical machine beside it is impervious to it.

As a very knowledgable man once told me, "If devicenet was so darned great, why isn't everybody using it?"

Yeesh

End Rant

TM

Workin' backwards through the listings...

Tim,

I think maybe you don't know how profound, and all encompassing, your statement is.

"If it Ain't Broke..." applies equally to methods as well as materials.

The word "methods" is what I'm focusing on. I'm gonna read that as "Procedural Methods".

"Procedural Methods" apply to people as well as to machines. I could have said "...as well as to systems", but then, people, groups or individuals, are systems too!

I just want to point out that, whether a procedural method is applied to the development of a mechanical process, or the mechanical process itself, or to something as mundane as filing purchase orders, any failing, in that method, is a human failing.

WE ARE THE WEAKEST LINK!

This failure occurs because someone didn't look at the procedure from a system point of view.

Looking at things from a "system point of view" means making judgements based on what is best for the system - not from the point of view of the whining few that say "I caaaaan't" do what is necessary to support the needs of the system. That applies to mechanical devices as well as people!

Now, I have to admit,...

CAUTION: EXCESSIVE EGO ALERT

...my programming efforts have increased production capabilities by more than $5,000,000.00 (that's 5-Million Dollars) per year.

END: EXCESSIVE EGO ALERT

As a result, I've been given free license to do damned near anything I want to do. That puts me in a unique position. I'm essentially in-charge!

I can certainly appreciate where you are coming from - I was there, for a loooong time! But, sooner or later, if you are lucky, you'll find yourself in a position where you can "establish yourself" by simply being willing, and able, to take ownership of a process. That means, being willing to stick your neck out on the chopping block!

Somehow, by one means or another, you have to simply jump in, take ownership, and then show them what you got! That's the way it's always been!

Try looking for that one particularly nasty process that no one wants to deal with. Grab it and show 'em what you got!

Ron,

I have to say, some of the statements you made were contradictory. The rest of what you said supported what I said.

I did not challange any machine, or process, that meets or exceeds expectations. If a system is capable of producing more than is being produced, how can I complain?

I challanged only those that could be made better. Those that could be made better to meet todays incredible efficiency requirements.

To quote what I said...

I say, quoting Tom Peters, "If it ain't broke, break it!" Everything can be made better, if a good mind and a later (if not latest) technology is applied. The name of the game, in these days, is efficiency! The older "slam-bang" methods are losing time and money!

In a lot of cases, it's simply a matter of looking to see how things are done. I've run into a lot of cases where things are done in a manner that might have been good in their day, but today, they are seen to be incredibly STUPID, INEFFICIENT and COSTLY !!!

So, if you have an idea that you know can improve on a particular process, BREAK THAT DAMNED PROCESS! Just so you have to fix it - better!

Everyone knows, it costs money to make money! So, if the current situation ain't the latest and best, then the current situation is losing money!

That's all I meant and that's all I said.


That's all I can can do for now, kids**. Catch you later.

**Don't think I'm being trying to be superior. I call the Vice-Presidents of my company Bobby and Tommy. We all need to know that we all are, after all, just a bunch of kids!

Terry,

>>I just want to point out that, whether a procedural method is applied to the development of a mechanical process, or the mechanical process itself, or to something as mundane as filing purchase orders, any failing, in that method, is a human failing. <<

I agree. Inevitably, if the machine fails, be it design or device, it is my responsibility for choosing the wrong tools for the job, or applying them incorrectly.

I do, however, get a little tired of being handed flaming bags of dog **** and ordered to turn them into functioning equipment Yes, it's the nature of the beast, and all that "opportunity" stuff, but if you've been doing this for years, you've doubtless gotten frustrated with it yourself before as well.

>>This failure occurs because someone didn't look at the procedure from a system point of view. <<

You are correct. In this instance, I do not speak the system's language well enough to address the issue myself, thus the "ringer". Which only adds to my frustration level. Grrrrr...

>>CAUTION: EXCESSIVE EGO ALERT <<

Just remember, one "aw shiiit" negates a whole lot of "attaboys"!

We're getting deep on this adage stuff, huh?

>>I can certainly appreciate where you are coming from - I was there, for a loooong time! But, sooner or later, if you are lucky, you'll find yourself in a position where you can "establish yourself" by simply being willing, and able, to take ownership of a process. That means, being willing to stick your neck out on the chopping block! <<

I've managed to do this on a number of occasions, and a few instances here as well. Enough to garner some respect, but not enough to carry any authority with people who insist the "red wire carries the electricity better than the blue one".

Thanks for the advice and encouragment, and don't mind me -- I'm just spouting off

TM