ASForrest

Hi guys, I'm trying do do something I haven't done before in a PLC program and wondering if it can be done simply. I'm basically creating a queue of recipes for the system to run. So I've used an FFL to add recipes to my queue, and then when the next recipe is loaded into the batching sequence, an FFU removes that recipe from the top of the queue and shifts everything else up. (Side note: As far as I'm aware, I use the same Control for the FFL and FFU instructions, can someone confirm or deny that rumour? ) But what if I want to add a new recipe in to the START of my queue, rather than the end? Is there an easy way to shift everything in my queue down one place, and add a new recipe into position 0 in the array? In my mind, it's similar to a BSL (Bit Shift Left), except I'm using INT's not BOOL's. Thanks!

I have heard that your local RA office may help you if you can jump through a lot of hoops to prove that you own the machine and are authorised to access the code. That's where I'd be starting.

I don't believe it matters - just select the highest revision you can and it should be OK. The only trick to watch for to make the module happy is the chassis size: you have to set the correct chassis size in your PLC project, and also in the module itself.

For inputs, put them as "required". If you don't need that particular input/output, you can just put a "1" or a "0" in the required place: As for outputs, you have two options that i can think of off the top of my head: Leave them as not required. If they are required, then copy the output to the relevant tag on the next rung: Or, leave them as required, and just create a dummy tag that you can assign to the AOI where it's not required: Hope that helps!

No, I've not used any security. I know there's a different mindset over in the USA (and possibly in Argentina too), but here it's generally considered very poor form to put passwords or security on PLC programs. The customer is buying the machine, it's their machine, and if they want to be able to make modifications to integrate it with their process then it's their right to do so. Yes, there are exceptions to this - and there are still plenty of places that lock up PLC programs anyway - but from my point of view it's not a good look for my business. Even if it means that I get extra work because they are forced to use me later on to make any changes, they won't be using me willingly. And they won't speak highly of me to others. It's a small industry, if word gets out that my systems are a long term pain in the backside, I'll start to find very quickly that I'm not winning as many jobs as I used to. Anyway that's my rant done with. Doesn't really help you, I know. Sorry!

I believe the "service" version of RSLogix 5000 has this level of functionality - but there's nothing to stop someone from getting a higher version and editing. Depends what you're trying to achieve/prevent

A good example of it's use is where you receive an integer (16 bits) from a device, where the first 8 bits are boolean status information, and the last 8 bits are a value like a status code. I want to get a hold of just that integer value, I can use the MVM instruction. e.g. N7:0 is the value I want to extract the value from N7:1 is wher I'm going to put the extracted value N7:0 is 0100 1011 0001 0011. I'm only interested in the last 8 bits: 0001 0011, which is decimal 19 --------------------------| MVM || Source: N7:0 || Mask: 2#0000000011111111 || Destination: N7:1 | --------------------------Note: the 2# before the mask value is to indicate that I'm entering a binary value. You can also enter it in decimal or hex but it's easier to see what's going on with the binary. N7:0 = 0100 1011 0001 0011Mask = 0000 0000 1111 1111N7:1 - 0000 0000 0001 0011You can see that N7:1 no contains only the last 8 bits - the ones that were marked with a 1 in the mask - and so now, N7:1 = decimal 19, which is what we were after.

A digital input is not going to cause a processor fault. A processor fault is caused by an error in the logic, like attempting to address a non-existant register, getting trapped in an infinite loop, etc. The fact that your sensor (appears to have) failed is most likely sheer coincidence. Treat the two as separate issues and you'll get a lot further. What specific error code does it give when it faults? A screenshot would help.

And I'll bet that this was the response from the operators when the alarm went off: "Bloody alarm! Why would they put such a loud alarm on this thing? It's not like we're f***ing deaf! And that f***ing strobe light is annoying as hell! Bloody Ken, he has no idea what it's like to be an operator! And what the f*** is all this French on the HMI? Does he think we're f***ing French? Oi, Robbo, get the f***ing fire hose onto that bloody horn and see if you can shut it up!" "Oh look, there's smoke coming from the bearing of that fan. If it wasn't for this f***ing noisy alarm we might have heard that bearing noise!"

I've had trouble with Windows 7 as well. Make sure you disable any firewalls, and any other network adapters (e.g. wifi). If you're using VM's, also disable the host wifi adaptor. Using this method it works for me pretty reliably.

Huh, hadn't come across the sort instruction! Good call Mickey. Note to the OP - there is also a risk of faulting your processor if you set up your sort instruction wrong ;) JRoss's example is a much simpler and far less likely to fault the processor option. I tend to overengineer things like this sometimes because I tend to think things like "sure, this works for 5 values, but what if I had 500? How can I make this easily scalable and reusable?" So if it's a one off with 5 values, I've probably overthought it and the other two options here are probably much more suitable than mine ;)

Seeing as they're all in sequential registers, I would use indirect addressing. Set a "pointer" integer to 1 Set a "lowest number so far" float to a number higher than the highest number you'll be comparing If F8:[pointer] is less than [lowest number so far] then move F8:[pointer] into [lowest number so far] Provided pointer is less than 5, increment pointer From there you can use a JMP and LBL to repeat the last two steps, which will perform all the comparisons in one scan, and then execute your logic after that. Or, you can just let it roll around and do the next comparison on the next scan, so the comparison will take 5 scans. If you use this method, you will need to block your following logic from executing until the pointer reaches 5. FYI I've not done indirect addressing on a PLC5 so I'm not sure of the syntax; what I've shown above is almost certainly not right, but it should at least give you the idea.

There are a great many different options, but you'll need to be a bit more specific about what sort of data you want to log, how you want to be able to view it, how long you need it stored for, etc :)

I generally just use one bit as a heartbeat, and flash it on/off every 250ms or so. Then at the other end, if the heartbit bit stays the same for 5 seconds or so, I've either lost connection to the other PLC, or it's stopped executing code (faulted/program mode/etc). Just my preference, but I think it's simpler than using whole integers. The only thing you have to be aware of is the frequency of your flash, and the frequency of the communications between PLC's. I set one up once where the heartbeat would change state every 500ms, and the communications were updated every second. So despite the fact that my heartbeat was changing all the time, every time the remote PLC polled it, it was in the same state. I changed the heartbeat to switch every 750ms and the problem went away :)

Check the subnet mask on the SLC. My guess would be that it's set to 255.255.255.0 and so is "ignoring" your laptop unless it's on it's own subnet

I agree, always best to do it in the file rather than on the hardware. If you DO want to do it on the hardware, you have to do the opposite of what I cautioned before - make sure that your PV is NOT set to overwrite the RSLinx Enterprise setup when it runs the file. i.e. tell it to use it's own internal IP address targets, not the ones from the file it's running.

Yes, you can. However, be aware that restoring the project scrambles your user data. So you will need to know all the usernames, passwords and permissions that existed on the PVP before you uploaded it, and re-enter them manually. Also, make sure that you copy the new IP address to both the design and runtime tabs! Lastly, make sure that your PV is set to overwrite the RSLinx Enterprise setup when it runs the file. Hope that helps! As always, make sure you keep an untouched backup copy of the original .mer file, so that if it all turns sour you can put it back and get yourself out of trouble.

Agreed. If you only have v17, there are no cheap options. v17 doesn't support any of the new controllers with onboard I/O, so you have to buy CPU, power supply, and then I/O, and it adds up very fast. No matter what hardware you buy, you're going to need new software - either RSLogix 500, or a newer version of RSLogix 5000. So if you have to buy new software anyway, go with what you already know. Plus, RSlogix 5000 is the future of AB PLC's, RSLogix 500 won't see a lot more development from this point I don't think.

This is correct - you will need at least version 20. But if you're only on a trial version you'd presumably have to be buying a paid version at some point anyway. And if you're comfortable with RSLogix 5000, and never used RSLogix 500, then I'd suggest it will definitely be worth the extra hardware cost, you will save the money back in hours for sure.

It may be slightly more expensive, but you could also use: - 1x 1769-L16ER-BB1B (compact logix with digital in, digital out, ethernet, onboard power supply) - 2x 1734-IE8C (analog in expansion card) - 2x 1734-OE4C (analog out expansion card) - 4x 1734-TOPS (terminal base for the expansion cards) That would give you 16 digital in, 16 digital out, 16 analog in, 8 analog out. Note that you then use the Logix5000 platform to program it, not the Logix500 platform. So if you don't have that software, it'd be much more expensive - but if you do have it, you could probably save enough time on the programming to offset the slightly more expensive hardware. Also, a note - those analog cards are 4-20mA ONLY. If you need 0-10V analog, you'd have to use something different

Just to ask the obvious question - you are trying to add this new module to your ethernet card, not your chassis, aren't you? :)

I can't speak for rdrast, obviously, but my thinking would be the same as his appears to be. I'm definitely not suggesting you stick with the PLC-5's. But doing a straight "conversion" doesn't take advantage of all the benefits of the RSLogix5000 platform, like tag based addressing, UDT's, AOI's, etc etc. So yes, if I were you, I'd be sitting down in a quiet corner and going through the PLC-5 code in detail, work out what each section is achieving, and then actually write new code to replace it, rather than just import it into the new platform as-is. As rdrast said, I think in the long term it would be highly worth it. I've come across Compact/Control Logix PLC's that have been just converted and left (and even in some cases, brand new Compact Logix PLC's programmed as if they were a PLC-5 or SLC: "where's my N7 register? Never mind, I'll make my own. New tag: N7, type INT[100]. Done. Comments? Nah!") and given the potential of the platform it's woefully cumbersome.

Ken's (as usual) probably right on the money. I found exactly the same thing going on after I flashed firmware from v13 to v19, and it took a trip to this forum to work it out :)

No problem, yep that's about the way I would have done it. Glad you got it working!