Thank You Ron

Snide

Member
Join Date
Oct 2005
Location
Pittsburgh
Posts
73
Ron,

Thank you, your class was great. I didn't realize how much I didn't know about PLC's. You really know a lot about PLC’s and you can teach it too (a rare find). I’m really glad I had the chance to meet you. I hope to attend another class soon.

~Amy
 
Greetings Amy,



I’m not sure that I’d call your 3-day crash course a “class” ... but you’re certainly welcome ...



anyway ... here are two important rungs that we didn’t get time to finish up ... for anyone who's interested, these go along with the material in Amy’s original thread about a Remote I/O link between a 1747-ASB and a 1747-SN for an SLC-5/05 system ... this is part of one answer to the “what’s-going-to-happen-if-the-blue-hose-cable-breaks?” question ...


snide20.JPG

 
Last edited:
Ron, did you happen to send me snail mail with the processor to practice on? i forgot to tell you i'm in suite 300. Sorry about that. Amy
 
more about the M0/M1 files ...

Greetings to all,



I just received the following (paraphrased) request from Amy in an e-mail ... since it might be helpful to someone else in the future, I thought that I’d cover it here ...



In the program that you posted (in post #2 above) you had the M address M1:9.10/10 ... I thought it had to be from 100 to 3200. (example: M1.9.100.) Could you explain this to me?



basic (slightly simplified) idea: when using Block Transfers through a 1747-SN/B Scanner module, the information moves through a “Block Transfer Buffer” as it is being transferred to/from the SLC processor ...



there are 32 of these “Block Transfer Buffers” available for the M0 file for output (Block Transfer Write) transfers ... these are numbered M0:e.100, M0:e.200, M0:e.300, etc., through M0:e.3200 ... note that the “e” must be replaced with the slot number of your 1747-SN/B Scanner module ...



NOTE: since Amy has her 1747-SN/B Scanner module installed in slot number 9 for this application, I’ll use “9” for the rest of the examples in this post ...



there are also 32 “Block Transfer Buffers” available for the M1 file for input (Block Transfer Read) transfers ... these are numbered M1:9.100, M1:9.200, M1:9.300, etc., through M1:9.3200 ... (remember that the number “9” in these addresses applies to Amy’s application - due to the position of her 1747-SN/B Scanner module in slot number 9 of the chassis) ...



so that’s the (slightly simplified) story on the M0/M1 “Block Transfer Buffers” ... note that the addresses of the buffers range from 100 through 3200 ... and they always end with “00” ... remember, Amy, we covered these ideas when you came down for that 3-day crash course ... you used these M0/M1 buffers when you set up the Block Transfers ... I think that you’re OK with these ideas ...



BUT ... there is MORE to the M0/M1 story that we didn’t have time to cover ... let’s continue on ...



the following screen shot is taken from page 4-26 of the 1747-SN User Manual ... sorry that it’s a little blurry - but the forum won’t allow anything wider than 550 pixels ... consult the original if you need more detail ...



snide30.JPG





this chart shows how to access word 10 of the M1 file to determine which of your remote I/O devices are communicating OK - and which ones are not communicating properly ... this could be VERY important information in certain applications ... basic idea: if the remote I/O cable (blue hose) gets broken, then maybe the SLC processor needs to know about that situation - and possibly sound an alarm for the operator, etc. ... making proper use of the bits in word 10 of the M1 file will let us write ladder logic to take an appropriate action ... and that’s the type of logic that I used in the example rungs of my post #2 ... you should be able to pick out the exact status bits that are required for your two remote I/O chassis ... I’ve highlighted the pertinent information in yellow ... as long as you stay with the same configuration that we used in the lab, these should be the correct bits to use ... you can (and should) confirm that these work as planned on startup day when you commission your program ... basically, you get everything else working - and then disable each remote chassis - one chassis at a time - and see if the “can’t communicate” alarms will work correctly ...



one more point ... the addresses that I used for the alarm bits in my example rungs were “spare” outputs on the equipment that you worked with in the lab ... these will NOT be correct for your application ... you’ll have to decide what (if anything) you want to happen when a communications fault happens ... if the answer is “nothing - just ignore it” then I’d recommend that you use a dummy (do nothing) internal bit for the outputs of these rungs ... you could (of course) just leave the rungs out completely if you’re not planning to use them for anything ... but ... I’ve got a hunch that someday somebody is going to want a “communication error” to be properly handled - and not just ignored ... maybe a popup banner on the PanelView would be enough? ...



I’ll try to find time this weekend to take a look at the RSLogix5000 conveyor program that you e-mailed ... what I’d suggest that you do is post the same file on the forum in a new thread and give all of the members a chance to help ... my work schedule is rapidly filling up now that the holidays are over ... STOP! ... before you post any such file, make sure that your boss doesn’t consider the material to be proprietary or “trade secret” type stuff ... most “consulting” companies such as the one you work for are very picky about who gets to look at their programming work ... you’re welcome to keep sending the files to me by e-mail and I’ll treat them as confidential ... but I just can’t promise a quick response every time ...



I hope that this helps ... please post again if you need more detail ...
 
Last edited:
Ron, Thanks I'll look over this some more this weekend. I'll try to do the MicroLogix this weekend too.

I want to come to another one of your classes, but i haven't found a good time to ask my boss. He's only been in the office a couple of hours this week.

I hope one day to know all that you know (Smile).

Thanks Amy
 

Similar Topics

Replies
49
Views
10,758
I've been doing Modbus for 20 odd years but almost never do I have to use a slave simulator. Until today. I used Peak HMI's freeware RTU slave...
Replies
2
Views
1,946
So I have a personal project where I want to use a photosensor relay (no/nc) as inputs on my Siemens logo. When the lights are on I want the...
Replies
4
Views
2,499
Hi All, I'm curious if anyone else has had this issue. I am the site coordinator and purchase ten seats of Rockwell Software each year for our...
Replies
18
Views
10,604
:banghead: Dear Rockwell, as we are in the final month of the year, a time that most integrators are swamped with control upgrade projects...
Replies
21
Views
6,635
Back
Top Bottom