Step7 - philosophical question, = or S/R, which is better?

[ToolGuyFred]

Funnily enough when I do use S/R, I have programmed multiple instances of the same address being switched, this is because, depending on the requirements of the code, I do jump around programs at times.

That's kind of making my point. Put yourself in the position of the control guy 10 years from now, trying to troubleshoot the equipment. The most elegant solution isn't usually the most maintainable. Your example would be much easier for someone else to understand if you had a different address for each instance of your S/R then ORed them all together before they were read.

When I started in this game I wanted other programmers to admire the ingenuity and concise-ness (is that a real word?) of my code. Now I just want anyone to be able to understand how it works so they can modify it or fix the equipment it controls. Perhaps its because I don't get paid extra if I get called out in the middle of the night...

 

[RMA]

Interesting discussion, more evenly balanced in the preferences than I had expected.

Its certainly simpler to get your head round logic which is continuously scanned. For most applications using modern PLCs this is just fine.

This is probably true if you have done all your programming on PLCs. If you come from an interrupt driven background then I think it's easier to follow code that only operates when it's needed. I like programming this way because it makes it easier to plan the program with a Flow-Chart and carry this over (more or less) one to one into the program - you certainly can't do that if everything runs continuously.

Having said that, I must admit I feel sorry for anybody who's only worked with PLCs who ever has to take over one of my projects!

 

[ToolGuyFred]

Having said that, I must admit I feel sorry for anybody who's only worked with PLCs who ever has to take over one of my projects!

This would be the electrician with his laptop calling you/me in the early hours of the morning...

I understand where you're coming from. I have done microprocessor, CNC, PC and PLC control programming. If its microprocessor code and to a lesser degree PC or CNC then you're less likely to have someone delving into (and struggling with) your code. A lot of the gear I have worked with has been food and manufacturing industry. The customer usually wants something that anyone can fix quickly. If the software author has to make a site visit every time there's a problem then the scope for repeat orders becomes very limited.

 

[PeterW]

That's kind of making my point. Put yourself in the position of the control guy 10 years from now, trying to troubleshoot the equipment. The most elegant solution isn't usually the most maintainable. Your example would be much easier for someone else to understand if you had a different address for each instance of your S/R then ORed them all together before they were read.

When I started in this game I wanted other programmers to admire the ingenuity and concise-ness (is that a real word?) of my code. Now I just want anyone to be able to understand how it works so they can modify it or fix the equipment it controls. Perhaps its because I don't get paid extra if I get called out in the middle of the night...

I think you'll find the problem is not the coding but the documentation that goes with the coding.

Although true enough it can be inappropriate, where it is appropriate the documentation and the code structure should ensure the code is maintainable.

I don't agree in OR'ing multiple flags just for the sake of it. If a flag has a specific function and that function is enabled at more than one point then so be it.

I'm not saying it should be that way as a matter of course either.

 

[JesperMP]

Now I am almost certain that what Roy is referring to is some kind of state machine. In a state machine you have to define all possible states that a sequence can exist in, and all the possible transitions between states (you can call the transitions 'interrupts' if you like).
When you look into the code of my state machines, it is very confusing if you dont have the original state diagram ('flow chart' if you like) to look at (made with pencil and paper).
Because of the added complexity with state machines all efforts should be done to avoid having to look inside the code. That means that there must be HMI information about the current state, and which transitions are wating to activate the next state.
If you have to troubleshoot the code of a state machine, I find that it is anvaluable if there is an in-PLC log of all the states and the transitions.

One can ask why use state machine then ?
The answer is that if you try to code something complex with the continously scanned '=' approach, then you will end up with code that is equally confusing.
State machines is a method to bring order to the confusion.

 

[AMAZINGAHMED]

if you try to code something complex with the continously scanned '=' approach, then you will end up with code that is equally confusing.

I totally agree.

State machines is a method to bring order to the confusion.

And I liked this statement.

 

[RMA]

This would be the electrician with his laptop calling you/me in the early hours of the morning...

Theoretically, yes, in practice fortunately, not likely.

Now I am almost certain that what Roy is referring to is some kind of state machine.

You're right Jesper, this is a direct result of 30 years+ on DCS Process Control systems for the chemical industry before meeting up with PLCs for the first time.

The telephone call at three in the morning is unlikely for the simple reason that since I've been involved with PLCs (~2001/2002) I've only done three projects entirely on my own. Of these, two belong to the peanuts category and the third one, which led to me being a regular visitor here, was the Rossendorf High Magnetic Field Lab. In fact, that project has more similarity to a Process Control project than what one would normally understand under "Maschinenbau" (what's the official English term, Jesper?).

Most of the time I've either been a member of a team (2001 - 2003) or, more recently, I've been involved in sorting out or modifying what other people left behind.

Edit: For those newcomers who don't know the story of the Rossendorf project, you read all the gory details here on Ron's site - thanks Ron!

 

[ToolGuyFred]

I don't agree in OR'ing multiple flags just for the sake of it. If a flag has a specific function and that function is enabled at more than one point then so be it.

And neither do I. In your example, one of the different multiple flags would point to the specific point where the flag (which has a specific function) is enabled. If you enable the same flag in multiple points, you have to examine every point when you're troubleshooting - in my experience more time consuming (and time's money).

 

[PeterW]

And neither do I. In your example, one of the different multiple flags would point to the specific point where the flag (which has a specific function) is enabled. If you enable the same flag in multiple points, you have to examine every point when you're troubleshooting - in my experience more time consuming (and time's money).

OK, I'll give an example where its appropriate.

3 pumps are used for transferring product, the pumps used depend on the recipe.

When the recipe's selected and the code for that recipe (including a block only used for that recipe) is run, it set/resets latches to enable the pump selection. (This may even be writing a bit pattern into a word, probably more common).

All recipes run a block for setting up their own individual requirements, some share a block.

Therefore the same bits are set/reset in different blocks.

You know where, because you know which recipe is run.

 

[ToolGuyFred]

OK, I'll give an example where its appropriate.

3 pumps are used for transferring product, the pumps used depend on the recipe.

When the recipe's selected and the code for that recipe (including a block only used for that recipe) is run, it set/resets latches to enable the pump selection. (This may even be writing a bit pattern into a word, probably more common).

All recipes run a block for setting up their own individual requirements, some share a block.

Therefore the same bits are set/reset in different blocks.

You know where, because you know which recipe is run.

Fair enough. Good example.