ASForrest

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.