Question against teachers opinion on book info

TurpoUrpo said:

Rockwell would do a huge favor renaming those to XIT and XIF. Examine if true and examine if false...

Click to expand...

or NO & NC like the rest of the world uses.

61131-3 2nd and 3rd Edition calls XIC "Normally open contact" and XIO "Normally closed contact".


61131-10 (was PLCopenXML) calls them both Contact, with the attribute negated. The description for negated says that it identifies it as a "negated contact".



CODESYS calls XIC "Contact" and calls XIO "Negated Contact".


Having sampled all three naming variants, my favourite is Contact / Negated Contact, but I am partial to following standards so "Normally [open / closed] contact" gets my vote.

janner_10 said:

or NO & NC like the rest of the world uses.

Click to expand...

No, those should go away from programming also.

Have a discussion with your maintenance grunt in the field who thinks if you have no contact in button, it must be "no" in plc code also and you will agree.

TurpoUrpo said:

No, those should go away from programming also.

Have a discussion with your maintenance grunt in the field who thinks if you have no contact in button, it must be "no" in plc code also and you will agree.

Click to expand...

So, we call then "And" or "And Not" from Instruction List? Or better, "Load" or "Load Not" from the old OMRON PLCs?

cardosocea said:

So, we call then "And" or "And Not" from Instruction List? Or better, "Load" or "Load Not" from the old OMRON PLCs?

Click to expand...

I kinda like the "examine if true" and "examine if false". We could also just say: if true, if false.

AND, OR etc. come from the rung structure, not from the instruction itself.

But in the end, this is fighting the windmill and I don't expect anything to really change.

I understand that Ron said to be gentle with the instructor, but…

You are literally paying thousands of dollars to learn something from someone that has no clue of what they are doing/teaching. That’s rough and not okay. I mean, this is literally fundamental step one stuff.

Code in structured text where it's simply "TRUE" or "FALSE", where TRUE = 1 and FALSE = 0. Problem solved.

I know, you don't have a choice because the instructor is teaching LD. Which brings up a question - why are they teaching PLC programming using LD for a Mechatronics lab course? If you aspire to be a Mechatronics Engineer, you will most likely never use that skill (Ladder Programming). However, I guarantee you will be coding/programming something where a textual programming language is used. Guaranteed!

cardosocea said:

Why is it a bad habit? The graphical representation is a Normally Open Contact.
Siemens, OMRON and I'm willing to bet 99% of other manufacturers calls this instruction a Normally Open Contact. Why aren't you wrong instead?

Click to expand...

Of course, I should have prefaced my statement with "In my opinion" because that is all we are talking about here, is everyone's opinions. I did not say it was wrong. I simply said it was a bad habit. "In my opinion", should have been added. I did think to add it later, but I missed my opportunity to edit. My opinion was based on my experience teaching. What confused students and what was less confusing. It was not based on what IEC says, or even what any of the manufacturers said.

This may be in the TL/DR category. I apologize for that. I am in no way saying this is the only way to teach this content. It's just how I did it. My take on this was that I was usually teaching people that had little to no experience with ladder logic, but maybe they were familiar with relay logic and/or the concept of normally open and normally closed contacts. And I was focused on A-B controllers.

This was all just my method. Everyone had their own style; this was how I approached it. I would try to cover the signal as it flowed from the field device to the PLC before I ever got to the instructions themselves. I would go through examples of push buttons with NO contacts. What would happen when you weren't pressing the button versus when you pressed it. Then do the same for a push button with NC contacts. We would talk about what you would measure if you connected a meter at the input module. I might have the data file or tag display open so they could see the data changing as I pressed and released buttons. I would try to make the association that a closed contact = 1 and open = 0. I tried to point out that the NO or NC contact was the device in the field and the device in the field is what put the 1 or 0 into Ron's "bit bucket". The PLC had no way of identifying if the 1 was from a NO button that was being pressed or a NC button that wasn’t being pressed. "Normal" didn't exist to the PLC.

Then, what you were seeing in the logic were logical instructions. I refrained from calling them contacts. They were always instructions. I would also sometimes say that relay logic was a representation of what you have. Ladder logic was a representation of how it works.

I would commonly refer to the XIC and XIO as “If Closed” and “If Open”. So if an XIC instruction had I:3/4 tied to it I would try to get them to make the connection that when the field device wired to I:3/4 had closed contacts, this instruction would be true. And when the contacts were open it would be false. I would describe that instruction as “If I:3/4 is closed”. I could say, looking at the logic I don’t know if those devices in the field are NO or NC, but I know when this device is closed and that device is open my output will turn on. Again, not representing what you have, but showing me how it works.

And I will definitely second that students would expect the instructions to visually change state rather than change color.

I can’t argue with what anyone else has said. Again, I should have added “in my opinion”. Because yes, this is all just my opinion. My methods evolved for years, seeing what worked for me and what didn’t. Also seeing how other people were covering this would give me ideas on how to adapt their methods for my own use . How I taught this on my last day was a far cry from how I taught it on my first day. It's funny. Back then I knew this content backwards and forwards, but I didn't really know how to teach it. That really does take time. But then again, as cardosocea suggests, maybe I am wrong after all.

OG

drbitboy said:

Understanding that the world does not revolve around me (oh my!) was when I finally started to understand

Click to expand...

Now finally you too understand that the world revolves around me instead





Sorry, I could not resist this one. Normal service may now resume.

why are they teaching PLC programming using LD for a Mechatronics lab course? If you aspire to be a Mechatronics Engineer, you will most likely never use that skill (Ladder Programming).

Click to expand...

I have involved with factory automation and PLCs for 40 years and I can't remember a time the incipient demise of ladder logic programming wasn't being predicted.

Steve Bailey said:

I have involved with factory automation and PLCs for 40 years and I can't remember a time the incipient demise of ladder logic programming wasn't being predicted.

Click to expand...

I never said or implied the death of LD.

I'm just wondering why a "Mechatronics Engineering" program would have LD programming in the curriculum. Maybe its a broader course that the OP is taking that includes LD in it, or maybe it's just an elective(?) that the OP selected.

We have a Mechatronics Group here at the company that I work for, with about 10 actual Mechatronics Engineers. A very talented group. We have a lab that we built for them and they get to play with a lot of cool "toys". They do a LOT of coding. Probably just as much as I do. Everything from Windows apps specific to their needs, to programming microcontrollers, Arduino and Teensy's specifically, to recently Garth Mini PLCs. They never.....never......not once.....for whatever reason, use LD in their daily coding tasks. That should be compelling information to an aspiring Mechatronics Engineering student. If you aspire to be a Controls Engineer, then yes, sure, learn LD. But my advice to the Mechatronics Engineering student aspiring to be an actual Mechatronics Engineer: Your time, work, and money would probably be much better spent learning one of the industry popular textual OOP languages. Take a good hard look at both Python and C/C++ specifically. You will see them often and use them early in your Mechatronics Engineering career.

I have also been in this field for a long time (digital electronics, analogue, & PLC including ladder, OOP you name it).
The original concept of PLC's was to mimic relays, so contacts were in their de-energised state and always called N/O N/C.
Even in FBD the logic symbols are the equivalent i.e. AND, NOT etc. FBD for example a NAND gate is NOT AND & in most FBD a little dot on the input is a N/C (not energised but true). TBH it does not matter as long as you understand what the naming convention calls it.
Most PLC manufacturers AB being the exception (no surprises there) use the N/O N/C convention.
Ladder is a very useful graphical language as it is easy to see the flow, even though I cut my teeth on C, C++ pascal, forth, Assembler & basic I still like ladder & for my customers maintenance staff it still seems to be the favourite, the only reason I have come across a client (engineering manager) requesting ST is because they did not understand it, they were not programmers but wanted the latest thing just like many people want the latest IPhone. as it is seen as cool.
In actual fact, even though I have retired, I have been asked on a couple of occasions to convert some ST into ladder.
I'm not saying any of the naming conventions are wrong & I have no problem with any of them, all I'm saying is it can create confusion.

first of all – I am now fully retired (as my precious little wife keeps reminding me) so I have no axe to grind here ... I'm just passing along a few personal opinions that I've developed over the years ... as with all opinions – please feel perfectly free to ignore them ...

until our Original Poster (Neopreza7828) comes back and fills us in – we're really not sure whether the mechatronics class he's currently taking is focused on teaching:

(1) programming skills (specifically, WRITING new code) ... or ...

(2) maintenance skills (in other words, READING and UNDERSTANDING existing code – in order to troubleshoot the plant's machinery when it suddenly quits running at 3:00 o'clock in the morning) ...

the skills between the two applications may have a certain amount of overlap – but they are definitely not the same ...

when I started building up my own PLC training business, it didn't take me long to realize that for every ONE programmer responsible for WRITING the code (just once-upon-a-time) there are probably:

(a) 5
(b) 10
(c) 100
(d) choose your own guesstimate

____ maintenance workers who might eventually be called upon, over the years, to READ and to UNDERSTAND the code in order to troubleshoot the equipment being controlled by the PLC ...

now Parky has brought up an excellent point in his previous post ...

In actual fact, even though I have retired, I have been asked on a couple of occasions to convert some ST into ladder.

Click to expand...

well, me too – except that I wasn't retired back then ...

before I went into business for myself, I once worked for a small systems integrator ... on several occasions, I was assigned (and got paid) to do exactly what Parky has mentioned ... specifically, take some existing program code – which was originally written in Structured Text - and translate it into the equivalent Relay Ladder Logic code ... and keep in mind that the ST code had been written by a competing integration company – and it already WORKED perfectly ... at least it worked when the sun was shining – when the birds were singing – and when life was tinged with a rosy red glow ...

but ...

whenever the plant's machinery suddenly stopped running (invariably at 3:00 o'clock in the morning) then it proved impossible for the plant's on-duty maintenance crew to interpret the Structured Text logic in the PLC ... indeed most of these guys had a problem even with good old-fashioned Ladder Logic ... at least the "green on the screen" indications MIGHT prove helpful ... (but sadly – there were no handy "good/bad" colors with Structured Text) ...

so ... Parky has told us that he's done a couple of "ST to RLL" translation projects on his side of the pond ... and I've done several on my own side ... keep in mind that there had to be some valid reason for customers to PAY to have these translations done ... money talks ... so what's the money trying to tell us here? ...

going further ...

over the years, many people have asked me which programming format I personally prefer ... Ladder Logic, Structured Text, Function Block Diagrams, Sequential Function Charts, Equipment Phases, and maybe even Egyptian Hieroglyphics ... the honest answer is that I loved them all ...

the reason:

keep in mind that I was in the bu$ine$$ of teaching maintenance personnel how to interpret their plants' existing PLC code ... so ... whatever new, bright, shiny objects came along – well, then – the more, the merrier ...

for anyone who's interested, there are some more details along this same topic in the following post which I wrote a few years ago ...

http://www.plctalk.net/qanda/showthread.php?p=783440&postcount=15

and I'll leave you with this short (16 second) motivational clip from a noted authority on programming ...

https://www.youtube.com/watch?v=VDRK0MyuuIM

stay safe – stay well ...

Ron Beaufort said:

and I'll leave you with this short (16 second) motivational clip from a noted authority on programming ...

https://www.youtube.com/watch?v=VDRK0MyuuIM

Click to expand...

LOL... never saw that one before, thats as bad as "If you've got a business, you didn't build that" but I may have to agree with him, he did not say program 'well' he just said program. I have a fast car and I can drive fast does that mean I can drive in a NASCAR race? Nope just means I can be another idiot on the road.

I learned relay logic before ladder logic. It was while I was in the navy. There were real relays with the power rail on the left and common on the right. We talked about normally open and normally closed relays.