PeterW
Member
I don't generally do mapping and I can assure you I am neither a poor or lazy programmer. I have mapped and I have not mapped, I have only mapped if the program requires it.
Programming methods
- Thread starter tommy23t
- Start date
I don't generally do mapping and I can assure you I am neither a poor or lazy programmer. I have mapped and I have not mapped, I have only mapped if the program requires it.
williamlove
Member
Yeah, good point.
I was talking to tech support and he agreed with my views, but that was a discussion in passing with the guy in the FactoryTalk HMI group. I intend to follow up on this informally with the guys at Rockwell in the months ahead and see if the heavyweights there can be asked to weigh in. So at this point I'm inclined to back off my assertion a bit.
Instead I'll just say the following:
- I don't map and my programs are highly organized and work well
- I have not seen mapping mentioned, let alone recommended (but I'll admit it might be all over the knowledge base, I just have not seen it)
- Although I like creating new stuff, I still have to edit lots of programs in the field and not that many of them use mapping
- When I encounter mapping, it is often in a state of disrepair, i.e. partial, inconsistent use, that does more harm than good
jdbrandt
Lifetime Supporting Member
Simulation counts too!
----------------------
I am in the "I've done it, and liked it, but don't do it unless I have a good reason" camp. Oakley has a good point there, but I'm surprised that nobody has pointed out another really valid feature.
Lets say that you map your inputs and outputs in sub-programs.
You could also have a different subprogram to map simulated inputs and outputs, and/or, simply turn off the sub-programs, and simulate your program right in your shop, without having to mess around with forces, etc.
But (and especially) for SLC500, you would not even need your full-blown I/O to be active...just a processor in a 4-slot with a power supply.
At the developement end, this is a big deal.
-=-=- FlameBait -=-=-=-
The HMI commonality feature is a big deal as well, since, for whatever reason, here we are, 30+ years into this business, and STILL nobody can make the PLC and HMI world really well attached, dynamically. I actually have a theory on this. As the cost of hardware has either stabilized or come down, and the power and functionality has gone up, the developement software has pretty much stabilized, for 90% of applications.
Worse yet, as connectivity has increased with competition, more and more projects are "Vendor A PLC connected to Vendor B fieldbus slave device and displayed on Vendor C PC-based HMI with a Vendor D local touchscreen."
So, now, the software engineering process is more about file management than process developement, and, of course, hoping that nothing changes, and, if it DOES, remembering all the databases, spreadsheets, and PostIt notes to update.
So, if you are one of these Vendors, whom do you spend your R&D time creating a connection to?
Or, do you just look at the marketplace, with hardly any creativity, and simply hook your wagon to whomever seems to be in First Place?
Or, do you create an Import/Export feature in your product, and just let the control engineers kludge their way to make a system out of the thing?
I've seen all of these approaches, and so have you.
----------------------
I am in the "I've done it, and liked it, but don't do it unless I have a good reason" camp. Oakley has a good point there, but I'm surprised that nobody has pointed out another really valid feature.
Lets say that you map your inputs and outputs in sub-programs.
You could also have a different subprogram to map simulated inputs and outputs, and/or, simply turn off the sub-programs, and simulate your program right in your shop, without having to mess around with forces, etc.
But (and especially) for SLC500, you would not even need your full-blown I/O to be active...just a processor in a 4-slot with a power supply.
At the developement end, this is a big deal.
-=-=- FlameBait -=-=-=-
The HMI commonality feature is a big deal as well, since, for whatever reason, here we are, 30+ years into this business, and STILL nobody can make the PLC and HMI world really well attached, dynamically. I actually have a theory on this. As the cost of hardware has either stabilized or come down, and the power and functionality has gone up, the developement software has pretty much stabilized, for 90% of applications.
Worse yet, as connectivity has increased with competition, more and more projects are "Vendor A PLC connected to Vendor B fieldbus slave device and displayed on Vendor C PC-based HMI with a Vendor D local touchscreen."
So, now, the software engineering process is more about file management than process developement, and, of course, hoping that nothing changes, and, if it DOES, remembering all the databases, spreadsheets, and PostIt notes to update.
So, if you are one of these Vendors, whom do you spend your R&D time creating a connection to?
Or, do you just look at the marketplace, with hardly any creativity, and simply hook your wagon to whomever seems to be in First Place?
Or, do you create an Import/Export feature in your product, and just let the control engineers kludge their way to make a system out of the thing?
I've seen all of these approaches, and so have you.
Back early - customer was not ready.
What I mean by mapping is not the I/O to and from the field - that is fixed. It is all the internal I/O and information received from external devices from communications such as Modbus RTU.
For example when I write alarm routines for a job I put all the alarm bits in contigious channels and all the acknowledge bits in contigious channels. It is then easy to use a bit counter function (BCNT) to determine how many alarm bits and acknowledge bits are on. Then use a simple compare and if the alarm bit total is greater than the acknowledge bit total turn on a buzzer or alarm light. The alarm bit total compare result can also be used to operate an alarm light separately - just a simple inline compare.
Similarly, I also have a standard routine for extracting data from, say, a Caterpillar engine and placing the received figures into a standard register area of my choosing. Easy the to copy and paste from program to program. Because the data is in a standard area I do not have to type in or change heaps of symbols and descriptions as they are copied across with the program.
This extends even further to the necessary floating point calculations to convert the CanBus J1939 protocol information into usable floating point or decimal values. As they are standard areas and formats from the engine, I am developing FBs for the claculations - finally a good reason to use FBs, with the exception of complex maths using ST of course.
The whole point is that I know where values are and can utilise the functions in the PLC to manipulate/use them very quickly and easily.
If I used auto allocation of symbols in the software I would not know where everything is and then have to try and use infernal symbol programming instead of the much faster direct number method.
It would also not be possible to use bit counters for my alarm routines as auto allocation just uses internal bits/words in no particular order.
It is very easy to use this method with Omron PLCs as I can just type in 10109 for channel 101 bit 9 and the software looks after it automatically. It would be just about impossible with Schneider, for example, as typing in %I.100.205.09 or the like would take so much time it is not funny.
By using my I/O allocation method I save LOTS of time and make more money.
Quick, highly functional and easy to use software is the most important thing to me with PLCs as writing and commissioning software is the most time consuming part of the job and my time is far more valuable than the cost of hardware, within reason. I would rather pay more for hardware and have really quick software development and commmissioning, get on to the next job quicker and make some more money.
The same goes for standard panel components. I use the more expensive motor circuit breakers with link bars to contactors and connection bridging bars across the top rather than having to spend time trying to get wires into fiddly overload units, although some are a lot easier to use than they were. Can also use a battery driver for tightening everything up and not finish up with RSI from heavy screw driver use. Same goes for other panel components such as terminals - I use Legrand - they utilise bridging bars that just knock in rather than having to tighten up a heap of screws. An added bonus is that the Omron G2RV relays utilise the same bridging bars - bridge 20 commons at a time in about 2 seconds.
It is all about getting the job done and getting on with the next job.
What I mean by mapping is not the I/O to and from the field - that is fixed. It is all the internal I/O and information received from external devices from communications such as Modbus RTU.
For example when I write alarm routines for a job I put all the alarm bits in contigious channels and all the acknowledge bits in contigious channels. It is then easy to use a bit counter function (BCNT) to determine how many alarm bits and acknowledge bits are on. Then use a simple compare and if the alarm bit total is greater than the acknowledge bit total turn on a buzzer or alarm light. The alarm bit total compare result can also be used to operate an alarm light separately - just a simple inline compare.
Similarly, I also have a standard routine for extracting data from, say, a Caterpillar engine and placing the received figures into a standard register area of my choosing. Easy the to copy and paste from program to program. Because the data is in a standard area I do not have to type in or change heaps of symbols and descriptions as they are copied across with the program.
This extends even further to the necessary floating point calculations to convert the CanBus J1939 protocol information into usable floating point or decimal values. As they are standard areas and formats from the engine, I am developing FBs for the claculations - finally a good reason to use FBs, with the exception of complex maths using ST of course.
The whole point is that I know where values are and can utilise the functions in the PLC to manipulate/use them very quickly and easily.
If I used auto allocation of symbols in the software I would not know where everything is and then have to try and use infernal symbol programming instead of the much faster direct number method.
It would also not be possible to use bit counters for my alarm routines as auto allocation just uses internal bits/words in no particular order.
It is very easy to use this method with Omron PLCs as I can just type in 10109 for channel 101 bit 9 and the software looks after it automatically. It would be just about impossible with Schneider, for example, as typing in %I.100.205.09 or the like would take so much time it is not funny.
By using my I/O allocation method I save LOTS of time and make more money.
Quick, highly functional and easy to use software is the most important thing to me with PLCs as writing and commissioning software is the most time consuming part of the job and my time is far more valuable than the cost of hardware, within reason. I would rather pay more for hardware and have really quick software development and commmissioning, get on to the next job quicker and make some more money.
The same goes for standard panel components. I use the more expensive motor circuit breakers with link bars to contactors and connection bridging bars across the top rather than having to spend time trying to get wires into fiddly overload units, although some are a lot easier to use than they were. Can also use a battery driver for tightening everything up and not finish up with RSI from heavy screw driver use. Same goes for other panel components such as terminals - I use Legrand - they utilise bridging bars that just knock in rather than having to tighten up a heap of screws. An added bonus is that the Omron G2RV relays utilise the same bridging bars - bridge 20 commons at a time in about 2 seconds.
It is all about getting the job done and getting on with the next job.
The Plc Kid
Member
It appears that I have offended some people by saying that not mapping equals a poor or lazy programmer. I still stand by my position that in my opinion the benefits of mapping outweigh the problems that some other has stated.
The things that are described as problems from mapping never seem to be a problem for me but that is a matter of personal opinion.
William Love made examples of the contrologix update time and how he codes to expect a possible change of I/O mid scan. IMO that is more work than mapping and you are basically doing the same thing again IMO.
Also the advantage of Asynchronous I/O updates is used in about 1-2% of programs and the rest of the time it is more trouble than anything again IMO
It is my opinion that not mapping is not a good practice but again that is my opinion.
If someone was building equipment for me the I/O would be mapped or I would buy from someone else.
At the end of the day it is the personal preference of the programmer and the project requirements and customer specs and what the customer is or is not willing to accept.
None of this was meant to be personal but I can see by the way that I said it many took it to be.
If I have offended you with my opinion then I sincerely apologize.
But my opinion is that not mapping is not a good practice in most cases and my opinion remains the same.
The things that are described as problems from mapping never seem to be a problem for me but that is a matter of personal opinion.
William Love made examples of the contrologix update time and how he codes to expect a possible change of I/O mid scan. IMO that is more work than mapping and you are basically doing the same thing again IMO.
Also the advantage of Asynchronous I/O updates is used in about 1-2% of programs and the rest of the time it is more trouble than anything again IMO
It is my opinion that not mapping is not a good practice but again that is my opinion.
If someone was building equipment for me the I/O would be mapped or I would buy from someone else.
At the end of the day it is the personal preference of the programmer and the project requirements and customer specs and what the customer is or is not willing to accept.
None of this was meant to be personal but I can see by the way that I said it many took it to be.
If I have offended you with my opinion then I sincerely apologize.
But my opinion is that not mapping is not a good practice in most cases and my opinion remains the same.
The Plc Kid
Member
Yeah, good point.
I was talking to tech support and he agreed with my views, but that was a discussion in passing with the guy in the FactoryTalk HMI group. I intend to follow up on this informally with the guys at Rockwell in the months ahead and see if the heavyweights there can be asked to weigh in. So at this point I'm inclined to back off my assertion a bit.
Instead I'll just say the following:
Therefore I have concluded that mapping is not for me. But I can assure the kid I am not lazy or a poor programmer. Here's to ya kid!
- I don't map and my programs are highly organized and work well
- I have not seen mapping mentioned, let alone recommended (but I'll admit it might be all over the knowledge base, I just have not seen it)
- Although I like creating new stuff, I still have to edit lots of programs in the field and not that many of them use mapping
- When I encounter mapping, it is often in a state of disrepair, i.e. partial, inconsistent use, that does more harm than good
And to you my friend.
My apologies if you took it personal. It was not meant that way it is just my opinion that not mapping is bad practice in most cases.We do not share the same opinion on that and that is ok. That is what this forum is about. You get help and opinions from many people. The OP has to make a decision as to which advice he or she wishes to follow.
Cheers
Generally would not map I/O to internal bits as it eats a bit of memory however on larger projects where simulation is required then it makes sense, even without a sim package this can still be done by putting the maps into blocks & disable the calls to them for simulation (only need the rack & CPU) you can write extra blocks of code to simulate the plant i.e. a valve etc.
brucechase
Member
Not being very familiar with ControlLogix, from what I am understanding, the I/O can update at any time. Got that. So some people buffer the I/O with mapping so if it does change mid scan, the program won't do anything funky.
My question then is if the input changes mid scan, does the bit that it is being reference to not change in mid scan?
My question then is if the input changes mid scan, does the bit that it is being reference to not change in mid scan?
Steve Bailey
Lifetime Supporting Member + Moderator
You put the mapping logic in one or more subroutines so that you have control over when it transfers the information from the input modules to the mapped bits and from the mapped bits to the output modules.
Clay B.
Lifetime Supporting Member
Probably want to watch that trick. If you stop a bit from scaning then it does not change state so if it was "on" the last time it was scanned then it is still "on".
As far as mapping goes. To me it does not take that much extra time to do, does not really use that much memeory and in my life makes things much easier. I can give alot of examples of why I think it makes things easier but it is at the end of the day a preference. Might as well ask someone why they like the color blue or green or whatever.
good point clay.I must no be thinking clearly today. but i do pefer the red stop button to the green or blue. but i have used this trick for start up to verify inputs before turning on outputs just not with the red stop button think that was in another post LOL
Clay B.
Lifetime Supporting Member
What I was refering to is using a conditional JSR. The problem here is that you can get locked out of controlling your outputs because you are not scanning them. I was not sure if you understood this.
yes clay and thank you. I was poking fon at the red push button thing from another post about novices . i forget sometimes I'M the only one who get my jokes will try and refrain from that. and you are correct about conditonal jsr you must be very careful about using them because you have to be aware of your scan update wether you map or not. I perfer to map its just the way i was brought up. just like red push button means stop and red mushroom means e-stop its just the way we do it here. I rarely find a program maped or not i cant understand but if i do a major mod i map it or a new program but for minor changes i leave it . I have never had this specked. maping is just that to me it keeps me from getting lost when things change.
brucechase
Member
OK so you control when it transfers. I assume (bad word) that with all this mapping fuss, you would only want it to transfer at the beginning or end of the scan (otherwise, why map). Isn't there any way in the ControlLogix programming to update the IO at the beginning or end of scan?
Similar Topics
Hey guys,
I was curious as to what is your preferred method for sequential/step programming? I have seen a lot of ways used such as Hex MOVs...
Hi all,
i know everyone has their own methods of programming, but i wanted to get some ideas.
we are about to get our first control logix plc...
Hi all, i am currently writing a PLC program from scratch for an existing packaging machine. There is an S5 PLC installed but soon we are going to...
I would like to know what constitutes the style of programming that is used on a particular project. There are conditional and step programming...
Hi, I am trying to set up a plc. I've never done any programming with ladder logic previously. I'm trying to set up a a program to turn a device...