How to simulate a FOR..NEXT loop?

"It is arrogant to assume that electricians are incapable of learning anything new or that they are not even interested."

Well, pardner, I is personally not jist referring to elctricians or technicians, but to any feller what has to de-bug a program, including the original programmer six months afterwards, and other engineer types involved in the project after the original programmer has moved on down the road. I've made a litle money over the years rewriting code that was so durned clever that it was undecipherable. Many of these program techniques was elaborate and tricky, way over my haid, but totally uncalled for in terms of fulfilling the primary function o' making the durned machine run. Time is money, and service time is the most expensive of all.

By all means, pardner, use the best tool fer every job, but if it ain't obvious whut is going on, mebbe another technique is really better even if it ain't as compact. After all, ya already paid fer all thet memory, so why not ues it?

gatenutenator hit it on the haid! Good commenting is esential, and if the code ain't obvious ya had better go to great lengths ta explain whut is happenin' and WHY it is gonna happen thet way!

KISS - Keep It Simple Stupid! The programmer ain't gettin' paid fer demonstratin' his expertise, he's gettin' paid fer makin' a machine or process perform as intended with the lowest total life cycle cost!
 
Last edited:
As for the concept of 'dumbing down' your programs to supposedly make them easier to understand or troubleshoot, I am strongly opposed. Following this maxim, one would avoid not only loops, but indirect and indexed addressing, subroutines, etc. for fear of confusing the unwashed masses. And without the tools, one would avoid many potential applications. Rather akin to burning books. It is arrogant to assume that electricians are incapable of learning anything new or that they are not even interested. Besides, getting equivalent functionality to a 'banned' technique will more than likely be 'long-winded' and bug-prone and genuinely difficult.

Well now being one of the unwashed masses what I see being said here is "It doesnt matter what you do they got the pretty little red/green lights to use!"

As far as electricians/maintenance people being capable of learning about plc programming. Why should they? They spent many years learning a specific trade to support their families/themselves. Why should they be forced to learn a whole new language/job just because.

OK some are interested so take the plunge, so they take personal time, company time and learn a little about this PLC thing. All of a sudden New machines come in that are based on IEC standards so no original code no can view/monitor/edit. Cant get the code? Why? The unwashed masses arent entitled to it.

Doesnt really matter any more, the day of the floor maintenance/electrician doing much with a plc is fading, too many features are added in every day and the programming is going to fadeaway from ladder altogether.

Dont know what dumbing down is, you should use what is needed, NOT use something just because its there.

When its all over with though make sure you tell us unwashed masses which pretty little light goes to what device, maybe we can figure the rest out somehow.
 
KISS

Some apply this principle as if it was Keep it Stupid Simple.
A number of years ago, I was shown a draft copy of 'programming guidelines' for PLC5's from a large corporation with substantial engineering resources. The guidelines purported to ensure that programs would be readily understood by all and sundry. It included statements like:
1. Never use SFC's
2. Only use on-delay timers, never off-delay
3. Never use retentive timers as sometimes they don't get reset

There was lots more but I've purged it from memory. In spite of their engineering resource, this document was prepared by a contract draughtsman.

The point, I think, is that these sorts of rules that artificially restrict the approaches to a problem are probably a reflection of the promulgator's learning experience and failure to (at least initially) understand.

"As far as electricians/maintenance people being capable of learning about plc programming. Why should they? They spent many years learning a specific trade to support their families/themselves. Why should they be forced to learn a whole new language/job just because. "

RS, do you really mean this? Should the automobile have been suppressed so blacksmiths could carry on making horseshoes? Should electronic fuel injection be banned because carburettor technicians don't want to know?
Nobody can be 'forced to learn' if they refuse. I accept that there are people who refuse to learn, but they must understand that the world does not owe them a living.
 
I have always been a proponent of the idea of using every tool at your disposal to accomplish those controls necessary to maximize the performance of any system. Just as a machinist or carpenter needs to be careful with the tools he uses, so too the PLC programmer must be careful with his tools!

Speaking of carpenters, (in general) there are three types of carpenters:
  • Rough Carpenter (Framer)
  • Finish Carpenter
  • Cabinet Maker
Each has their own set of tools. Assuming that the talents of each is restricted to their particular craft, you shouldn't ask one to perform anothers' specialty. You know what you get when you as a ask a Framer to build a Coffee Table (remember 4x4 furniture? Quaint!).

The analogy that I'm trying to present is not about the people, but rather, their tools and the particular talents required to use those tools.

Each set of tools and talents needs to be brought to bear in their turn. The task is not done until the Cabinet Makers' tools are brought to bear.

The Rough Carpenter can work with tolerances of +/-1/8".
The Finish Carpenter can work with tolerances of +/- 1/16".
The Cabinet Maker works with tolerances of +/- 1/32" or even 1/64".

If you consider the job done after the Rough Carpenter is done, then you should expect results no better than a Rough Carpenter (stress on the "Rough") can provide.

Likewise for the Finish Carpenter.

It is only after the Cabinet Makers' tools are brought to bear that the job is really done! (Of course, this assumes that these guys are good at their jobs.)

Bottom Line?
Use all of the Tools and Talents you can get your hands on to produce the best product you can!

Now, back to the subject at hand...

Comments are certainly required for those that get into the program.
It is very easy to make comments for programs that are reasonably organized (modularized, or at least, for smaller systems, properly ordered).

If you write spaghetti-code, you deserve all of the grief that comes your way. Of course, the backlash of spaghetti-code, even if you understand it, is that no one else will understand it! Even if it is commented!

Good Code almost comment's itself! (But don't let that stop you from actually entering the comments!)

The whole battle about how simple to keep code is generated because there are, in general, three different perspectives when it comes to programming and maintaining PLC's.

The three perspectives are...
  • OEM (Original Equipment Manufacturers)
  • Contract Programmers maintaining any number of different systems.
  • In-House Programmers maintaining Local Systems

The OEM wishes to maintain code in as much of a cookie-cutter fashion as possible. This is entirely reasonable. Sometimes, however, the OEM has to build a one-off (one-of-a-kind). Again, the OEM tries to keep the code as close as possible to the House-Standard. This practice is primarily designed to make things easier for the OEM. From the OEM's perspective, it is simply more efficient to do. I can't complain about that too much... after all, the OEM is in the game to make money.

In many situations, users are NOT ALLOWED to get into the program; only the OEM is allowed. In this case, there is no need to consider the ability (or lack, thereof) of those users that would attempt to maintain the system program. Certainly, Peter does not dumb-down his code so that it is easy for anyone to understand. He needs his code to be only as easy to understand as he requires.

Generally, as time goes on, an end-user usually finds that the OEM code does not provide all of the bells and whistles that an end-user (operator or maintenance) might like to have. Of course, the OEM will have every right to say "Yeah, but we built it to Spec!"

It's almost always the case that end-users don't really know what they want until they come up against a situation where they say, "Gee, I wish it would..." do this or that. They simply didn't know they were going to need it when they provided the spec.

In this case, if the code is closed, the OEM is contracted to provide the necessary changes. And again, the OEM will build to spec - you should expect no more, no less - a contract is a contract! The OEM is under no obligation to make the code easy for the local maintenance folks to understand - the code is closed. The OEM will, and should, make the code according to their own in-house rules. And so it goes...

If the code is open, then you might get a hold of a "Contract Programmer". And again, the code will be fixed, changed, updated, whatever, according to the agreed spec (or, at least it should be).

The result depends on how good this programmer is. A decent programmer will build the code in a reasonable fashion. If the changes require the use of a For/Next function, then the programmer should use it and explain how it's being used.

On the other end of the spectrum, you have your In-House Programmers. We are on-site, day-in and day-out. We have to suffer, on a daily basis, the consequences of the code we write. Those in-house programmers that care about what they are doing to the production folk and maintenance folk take it to heart when they hear complaints about this or that aspect of the code.

We also have time to contemplate more effective ways to do this or that. Some of the systems we work on are forever in development. We are also on-hand to explain to the operators and the maintenance folks how this or that works. I usually write up a "Technical Flash" explaining any new changes to the program and provide it to the operators and the maintenance folks.

I do not like phone calls at 2:00 AM and I do everything I can to prevent them from happening.

So, from my perspective...

K.I.S.S. ? ? ? ? Keep It Stupid, Simpleton ???

I say BULL! I also say...

K.I.C.K.A.S.S. ! ! ! !

Keep It as Complicated and Knowledgable As necessary to Support the Stategy!

When I design code, I make it only as complicated as it needs to be in order to accomplish the goal. I do not limit myself to using only those tools that everyone knows how to use.

If someone doesn't understand what's going on simply because the code is beyond their intellectual capacity to grasp (despite the comments, and I do make pretty good comments)... well... I can show them where the programming and math books are - then it's up to them. In terms of actual applications, I will not slow down for stragglers!

Anyone that is responsible for maintaining equipment and then, does not take the steps (intellectual steps) necessary to provide that maintenance should be replaced.

I go to great lengths to provide troubleshooting tools for the operators and/or maintenance guys. These are screens that are designed to indicate the status of all I/O for all system modules. Operators can call up a screen at any time, or, when a fault condition occurs, a screen pops up automatically.

One of the more helpful screens I have comes up when an operator tries to do something but the system won't allow it. If the operator pushes a particular button trying to perform a particular action, the screen pops up and indicates why the program will not let the action occur.

If a fault condition occurs, a screen pops up automatically, indicating the affected module and provides a "Go to Page #" for more details and possible solutions.

If operators and maintenance folk choose not to take advantage of the tools that are provided, what can you do?

At some point, after trying to make the program as idiot-proof as possible, you are faced with the need to get rid of the idiots!

This position can be taken only by those programmers that recognize that a programmers responsiblity is to use whatever coding is necessary to make the system as easy as possible for the users - not the programmer! Minimalist Programmers are the Bane of Operators and Maintenance folks!
 
>Certainly, Peter does not dumb-down his code so that it is easy for >anyone to understand. He needs his code to be only as easy to >understand as he requires.

I certainly don't dumb down code. Here at Precision Pickle Company we slice pickles with precision and fanaticism. Sometimes this requires code that is can be quite advanced. However, I feel it is better to raise people up than dumb code down. I don't work alone so, as stated above, it is very important to document the intent.
 
RS, do you really mean this? Should the automobile have been suppressed so blacksmiths could carry on making horseshoes? Should electronic fuel injection be banned because carburettor technicians don't want to know?

No, but those that chose to learn how are to be commended. Should those that dont know HOW be forced to? Should the blacksmith be forced to learn autos after spending a life learning to be good at what he does? We are talking choice here, your choice will affect hundreds maybe thousands of "skilled workers" now and tomorrow. You have the choice of writing 20 lines of code that many can understand easily or maybe 10 that uses advanced features that noone but you (maybe another programmer) can understand ever.

As Terry ( who is by far the most eloquent) stated, you use what is needed when needed with (hopefully) documentation to say what/why.

Here is how I see it, most electricians/maintenance can understand and deal with relay logic. That is what I dont understand, when RELAY LOGIC was prevalent so many didnt understand, so many devices used and large panels needed for the simplest machine. Today though it seems the olders guys (like me i guess) can understand relay logic and anything that resembles it. I dont know why any spec would state not use any form of timers/counters because they have been around for 40 yrs or so.

The thing is we understand RLL. The new features available with plc's make it more difficult, which for some means at age 50 or so with wife, kids etc we have to learn more more more, just to maintain our jobs. The new kids understand the programming stuff but are worthless overall for the old stuff or just plain electrical/electronic diagnostic/repair work (from lack of experience mostly). Thing is they wont stay long enough to learn the electrical part ( or in some cases the company wont put them in the postition). The bad part is after years of doing what is needed by the electrician/mechanic the programmer can make more money because they can understand just the programming and none of the electrical/mechanics. You understand how that works dont you, they make/fix the program but need the electrician/mechanic to understand precisely what is needed when it is needed.

Gerry, I dont know what you meant by your use of the term "unwashed masses". Most here are in some way either an Engineering graduate or in an Engineering position. I am not, I am an hourly worker that has to deal with a multitude of machines, plcs, and electrical/electronic devices...ie one of the unwashed masses I guess that has to understand what y'all have done with the plc.

This thread took a turn somewhere, the guy just needed to cycle 11 compressors. This isnt a complicated process (even for me) why the need for all the fancy ****? For/next loop, indirect-indexed addressing...gonna use C, C++ etc whats next? Why would anyone one thats not familiar with the machine(s), plc's, plc programming and results worry about all this FOR/NEXT, indirect/indexed etc etc etc. Why start there? A spec was stated DONT USE by him and another...is it written in STONE?

Shouldnt a more in depth look at the process be warranteed OR trying something like a sequencer (drum comes to mind cause us unwashed masses understand them) be used at first? Technically what I have observed is that more input devices are needed for a more accurate way to control what is being done.

Just another case where the electrical/epa/hvac certified guy is overwritten by the "kid" that knows how to program but doesnt have a clue about the system.
 
Well, I agree no blacksmith should be forced to give up making hoseshoes. The key concept here is force. But nobody should be forced to keep buying horseshoes either.
As you say, Terry is very well spoken and, may I say, verbose. He also says, and I quote, " At some point, after trying to make the program as idiot-proof as possible, you are faced with the need to get rid of the idiots! ". And to quote Peter, "I feel it is better to raise people up than dumb code down".
This thread has gone off on a tangent, but rather interesting, don't you think?
The issue of program documentation has been expounded. This is a vital component of any system, no argument from me. It is, however, quite a separate issue from whether or not for/next loops should be censored.
In this business, as in many technical fields, one cannot afford to stop learning. Age accords you experience, but that is not sufficient, on its own, to keep you up with the play. FYI, I am pushing 56, I graduated (with a diploma, not a degree) when nobody knew what a PLC was or might become (except, perhaps, Morley & Strueger).
In mentioning 'unwashed masses', I was presuming to speak for the attitudes of those who would make restrictive rules. You are right to be insulted by such an attitude, but please realise that it is not MY attitude.
And then we get back to the original problem - how to keep everybody comfy without spending any money. Every project has to contend with the eternal triangle of specification, time, and cost. A supplier knows you can't manipulate one side of the triangle without affecting one or both of the others. Consumers tend to be oblivious. So, Micrologix 1500, some thermostats - you need to reduce the spec, take an enormous amount of time, or spend a bit more money on hardware.
I could care less if Don uses loops, sequencers, or a truck-load of timers in his system - it's HIS system. I DO object to him being advised to avoid valid techniques for invalid reasons. And if he takes a fuzzy logic approach, I will cheer him on!
 
I posted this reply just a few minutes ago but it disappeared!

Don,

I've considered your HVAC problem over the last several days (with a few distractions along the way - Ain't TANGENTS GREAT!!) and have come to a conclusion or two...

Without using Temperature Sensors to determine which room has a legitimate need, you can not determine when someone has the thermostat set to 40-Below! Should that room have a higher priority simply becqause its thermostat is calling for cooling all of the time???

You might just as well let Mr. BIG have all the AC. Then, you might consider buying a bunch of those hand-held, battery-operated fans for the rest of the unclean-losers (dry-ice seat cushions?).

Under that condition, I can't think of any fair, equitable and consistent way to distribute the available cooling energy to the rooms that really need it.

Another good reason for using Temperature Sensors is so that you can determine which rooms are acting like Heat-Sinks. Those rooms will need special attention! At least, until you get them better insulated.

Your best chance might be to use a sequencer. It's easy enough to determine all of the legitimate patterns. If you have a room that needs a priority, ensure that the patterns for that room occur more often. Some rooms will already show up in multiple patterns.

I still think that Fuzzy is the way to go. Fuzzy is real good at handling any dynamic changes in the multitude of relationships. And you can add all of the flavorings you want (Positive or Negative priorities) on a dynamic basis if you wish.


TANGENT ! ! !

Whadaya mean Verbose???

I thought the word "Eloquent" was more appropriate! (Look it up!)

And HEY!

Did anyone make it down through all that there verbosity to see K.I.C.K.A.S.S. ? ? ?
I thought it was kinda cute! Made it up myself, don cha know?

I recognize that only those in my position can appreciate it.
What I worry about is that I'm the only one in my kind of position!
 
With all due respect...

Terry,

I've been waiting for you to comment on this again. And ultimately you let me down by coming to the same conclusion everyone else has: I'm screwed. ;) Actually, your first post indicated that you immediately understood the nature of the problem, which was a step ahead by itself. I don't mean to offend anyone here, a lot of people offered great comments and suggestions and I really appreciate the consideration it was given. It's not a problem that at first glance looks near as unmanageable as it has proved.

I'm not sure if you missed my last post in the "Energy Management System" thread, but I offered some additional thoughts on the problem (and ultimately an "algorithm" for the ladder program.) I think your case where one zone's thermostat is set to 40-below is handled, though maybe you see some problem that I don't. Would you please let me know if this is the case?

Here's the algorithm I ultimately worked out:

<blockquote><hr>I'm thinking of setting up each of the compressors with a starting priority, 1-11, with 11 being the most important. I've got 1 timer per compressor. When a thermostat calls for cooling AND the compressor kicks on successfully, I'm going to use that timer to lock that compressor in for a predesignated minimum amount of time. As long as the thermostat is still calling, it gets to run for X minutes. Now, if the thermostat is calling for cooling but the compressor can't come on due to load restrictions, I'm going to use the timer to start counting 5-minute (arbitrary number) intervals. For every 5-minute interval, I'm going to take the compressor's starting priority, add 2 (arbitrary number), and store it as an overall priority for that compressor. When any compressor's overall priority gets high enough, it's allowed to shut off any compressors for which the overall priority (when it last kicked on) is lower, provided that the running compressors have been allowed to run for their minimum time. The overall priority for a particular compressor gets reset to the starting priority for that compressor once it has run.

...

While my head spins when I think of trying to implement this in ladder logic, it should be possible, and I think it is about the best one can do, given the nature of the problem. I think there are enough "fudge factors" to ensure an adequate amount of "tweakability":

1.) Starting priorities for each compressor
2.) Minimum time each compressor can run
(My tactic for handling the case where a large compressor gets locked out for a longer period than desired is to just increase it's minimum time--it will eventually come on; when it does, let it run longer.)
3.) Time interval length after which you increase overall priority when a unit has been calling but not allowed to run due to load restrictions
4.) Amount that you increase overall priority per interval for which a unit has been calling but not allowed to run<hr></blockquote>

In your case where a particular zone is always calling for cooling, the corresponding compressor will inevitably get a chance to run (as long as it's waiting and not getting to run, it's priority keeps going up until it gets high enough to where it will kick out a lower priority zone once that lower priority zone has run for a preset minimum time.) However, once it runs, it's "overall priority" gets reset to it's starting priority, so other zones that have been wanting to run, will now (eventually--how quickly is adjustable by fudge factor #4 above) have a higher overall priority and until they each have a chance to run, the zone set to 40 below will be forced to wait it's turn (until it's priority is high enough AND the others' minimum time is up.)

Now, I may have completely misunderstood that overview on fuzzy logic that you pointed me to, but it SEEMS to me like I'm doing something of the sort with this algorithm. I have a lot of flexibility in my fudge factors for tweaking the system, and my system sort of balances itself out the best it can when it gets lopsided. (Or so I think.) It takes a situation with a lot of factors that in worst-case scenario will never be "good", and (hopefully) makes the most of it in the majority of less than worst-case scenarios.

[The reason the system prompted this other topic (the simulating FOR..NEXT loops--which I understand is not an optimal or "natural" programming technique in ladder logic, as so many were quick to point out) is that I am examining all the inputs (thermostats calling) in one ladder scan, and I need to determine within this one scan (loop through and calculate load for all running compressors whose minimum runtimes have been satisfied) if the compressor with the current highest priority has enough load space (compressors it's allowed to shut off) to run. A little messy perhaps, but when I contemplated doing trying to do it without looping in this way, a sharp pain shot through my head from temple to temple. My original plan was actually to loop naturally WITH the program scan, checking each of 11 compressors every 11 scans, but timers and one-shots didn't like it when I tried to use indirect addressing with them--how unfriendly!]

Thanks again for all the help,

-Don
 
ALRIGHT !!!
You Pushed the right button!
(Besides, I hate being beat by any mechanical problem!)

This assumes that you are still not going to use Temperature Sensors. Things would be a lot easier if you did!

The main objective should be to bring all rooms to set-point and then baby-sit only those that need it as they need it. In order to accomplish that, I think you need to do some investigating on your own and then have the PLC do some Empirical Data gathering for you. I think you need to know the following:

The capacity of each compressor ( 1-Ton = 12,000 BTU's / Hr )
The cubic-foot volume of each area serviced by a compressor.

Now, calculate the PER** for each compressor...

Comp #1 (12,000 BTU's / Hr ) / 35,000 Cu-Ft = .34 PER**
Comp #2 (18,000 BTU's / Hr ) / 65,000 Cu-Ft = .27 PER**
etc.
** (Phony Efficiency Rating) You may find that some areas are beyond rated size!

This gives you a really rough idea of which compressors are going to be most, or, at least, more effective - but not quite. Now comes the part where your PLC puts on the Sherlock Holmes hat...

This might take a while (a few days?), but as time goes on, the system should get better and better at making the "right" choices, instead of being subject to so much arbitrariness. The name of the game is to use the energy as efficiently as you can. And, thereby, reduce the over-all call for energy at all!

So... Using whatever priority system you want to use, have the PLC start to keep track of how long it is between a demand going off and the same demand coming back on. It might be seconds, minutes or even hours (though, not likely).

You also need to track how much longer the compressor ran AFTER the demand went off. This will give you a relative indication of how effective an area is at "keeping its cool".

As time goes on you will be able to identify the lesser efficient areas (Get them insulated!).

You should then be able to develop a regular routine for the more effective areas and service them BEFORE they call for it. "On-Time" for those areas should be predictable.

Meanwhile, as problem-areas issue calls for service, you can sacrifice some of the regular service time for those. This should be OK since you should be ahead of the game with the more efficient areas.

That's my best shot! Now, if you want code, let's talk!
 
I want code!!!

Terry,

<blockquote><hr>That's my best shot! Now, if you want code, let's talk!<hr></blockquote>See subject line. :) Actually, I have <u>finally</u> got my code working (I think) the way it needs to in my main sequence, now I just have a couple more parts to tie down, one of which seems a bit tricky, as I'll explain below.

<blockquote><hr>ALRIGHT !!!
You Pushed the right button!
(Besides, I hate being beat by any mechanical problem!)<hr></blockquote>Just keeping you on your toes, man. ;)

<blockquote><hr>Now, calculate the PER** for each compressor...

...

** (Phony Efficiency Rating) You may find that some areas are beyond rated size!<hr></blockquote>Ok, this PER of yours would be reflected in the value I am increasing my "overall priority" by (for a particular compressor) for every time interval that the thermostat is calling but the compressor can't come on due to load limits. I can adjust (or have the PLC adjust) this value for each compressor; currently I get the values dynamically from a data file. For now, however, I am going to assume the PER for each unit/zone is the same (probably a grossly invalid assumption, I know, but bear with me one more sec.)

The only adjustment I'm going to put into the program to start with is one where the PLC keeps track of the number of times in one day that a compressor is turned off while the thermostat for that zone is still calling for cooling. If the number of times that happens exceeds say 3 times, it will assume that this zone is just not getting cool enough with the minimum runtime (time for which the compressor <i>has</i> to be allowed to run) currently allotted to the compressor and it will bump up the minimum runtime for that compressor accordingly (not to exceed a certain value.) Then after a few days of running, I can evaluate whether or not the system is working effectively by seeing if any of the compressors have maxed out this runtime.


OK. Though the way you outline doing the system doesn't exactly match my own, much of it is similar and I get the feeling that it will work at least somewhat well (i.e., within the given constraints.)

The part I'm currently stuck on is logic to turn off compressors when another has reached a higher priority. I have to go through the list of compressors that are allowed to be shut off (the ones for which their "minimum runtime expired" bit has been set) and determine whether or not the load space that would be freed up when they shut off will let my "waiting" compressor run (otherwise, there's no point of turning them off if the thermostat is still calling.) I thought about loading a FIFO with the index of the compressor instead of setting a bit to indicate when a compressor has run for it's minimum time and can now be shut off, but I would need to be able delete values from the middle of that FIFO when it came time to actually shut the things off, a seemingly most unnatural way to do it. I'm looking for a better option.

I need a good way to keep a "list" of compressors (the ones that can be shut off) where it's easy enough to delete any value within that list. Also, this is a tricky part that requires (I think) looping within a scan, since I sort of need to determine in that scan if I'm going to shut a unit off or leave it run.

Whew. What a nice, fun problem.

-Don
 

Similar Topics

Hi there, I'm doing some extensive testing and commissioning with a slew of new Emerson PACSystems RX3i PLCs. It would be convenient to...
Replies
5
Views
80
Hello, I have a small application with a S7-1200 CPU 1212 and a KTP400 Basic HMI. When i am connected to the PLC with my PC i would like to...
Replies
1
Views
516
Hello everyone, i would like to test and run os server in pcs7 v8.2 project without rear PLC.i used plcim on ES and nettoplcsim and adjust the...
Replies
4
Views
1,302
Hi all, Im new to Allen Bradley software, so i was given a existing studio 5000 plc program. i already know how to use emulator and rslinx but as...
Replies
2
Views
1,365
I want to run a simulation of a program uploaded from a rockwell PLC, but I can't configure the CPU on the emulate to match the actual CPU.
Replies
10
Views
2,162
Back
Top Bottom