More Simple DeviceNet Questions

Well, I'm still chugging along on my DeviceNet project and came up with a couple of questions. Most of my questions come from the fact that A-B manuals do not address the PRO's and CON's of two methods of doing something. Anyway, here are a few questions (and thanks in advance to all who respond):

1) I have already mapped the discrete I/O through my SLC500 scanner (1747-SDN) on RS NetWorx for DeviceNet to my SLC 5/04 processor. I have some PointBlock I/O modules that I can energize outputs form the PLC and actually have solenoid coils hanging on them that work. I can jumper input points on the PointBlock modules and "see" them turn on data table bits in the PLC. How do I also "see" the various status bits available and where are these mapped? I specifically want to know when a "no load" (open solenoid coil) condition occurs. This is a legitimate parameter of the PointBlock modules.

2) What is the best way to know the status of each node? I would love to find a way of mapping a bit for each "node communications okay" signal. Where the heck are the locations of these bits spelled out?

3) In trying to obtain answers to the above, I re-read the 1747-SDN scanner's User Manual and it discusses mapping to M0/M1 files and also discrete I/O mapping (which I currently have implemented). What are the PRO's and CON's? of each.

Incidently, the way I have mapping to discrete I/O is set up to my devices really clean and convenienient. I have each node using that word of memory. For example, PointBlock outputs at node 6 are mapped to O:1.6 and inputs are mapped to I:1.6.

The SDN Status can be read from M1:X.210. The first word is the Node and Status code, if there are no errors it is 0. If errors exist the the upper byte is the node address and the lower byte is the error code that is displayed on the SDN.

Other status data is available up to M1:x.223 which includes an Idle Table, Failure Table, and Auto Verify Failure Table. Each table is four words in length. The individual bits represent each possible node address. The SDN Install manual breaks it down fairly well, I don't have the AB number for it as I have renamed it to something that I cen remember.

I've never worked with the Point I/O but I use this data for ADNs and various model VFDs

Hope this helped,
Chad

Chad,

Your reply reinforces the need to get my original questions answered.

When do you use discrete I/O mapping versus M0/M1?
Is node status available when mapping to discrete I/O?
If so, how is it done and where are the status bits located?

The manuals do not give direction whatsoever...

The very best manual for the 1747-SDN is surprisingly not the User Manual but rather the Installation Instructions, publication number 1747-IN058C-EN-P. I have pages from this document taped to my cube walls because I use it so often.

Use Discrete mapping whenever you can. This is fast (every scan of the controller) and simple because no programming is required.

M0 and M1 files need to have COPy instructions used to move their data in and out of the module, and those can take up to a couple of milliseconds to execute ! I only use M0 and M1 files when I have a large or slow data connection.

The other use for M0/M1 files is to get status data. The Device Failure Table is an array of words in M1:s.216-219 that has 1 bit per node number that will go high when the I/O connection fails to that device. The connection status bit for Node 6, for example, is M1:s.216/6.

I use a repeating timer to grab that data every 100 or 200 milliseconds during my machine operation.


Which exact PointBlock device are you using ? You might be able to select an I/O Assembly that includes the status data, or you might need to access it via Explicit Messaging.

Ken Roach said:

The very best manual for the 1747-SDN is surprisingly not the User Manual but rather the Installation Instructions, publication number 1747-IN058C-EN-P. I have pages from this document taped to my cube walls because I use it so often.

Click to expand...

I've been using both this and the User Manual

Ken Roach said:

Which exact PointBlock device are you using ? You might be able to select an I/O Assembly that includes the status data, or you might need to access it via Explicit Messaging.

Click to expand...

I'm using a whole mess of 1734D-IB8XOB8E PointBlock I/O modules. The method to my madness, although I only need a few I/O off of each, was to allow for expansion, keep all I/O parts identical (for customer spare stock) and the PointBlock has the onboard communication. You just buy one item, wire it up, and away you go. I've been impressed with how simple the hardware works.

Thanks for your help. I'll dig in further and play with the status from the M files as suggested. I'm sure glad that I did all of the discrete mapping and won't have to change it.

How do I also "see" the various status bits available and where are these mapped? I specifically want to know when a "no load" (open solenoid coil) condition occurs.

Click to expand...

The low 8 bits of the Input connection is the state of the eight inputs on the PointBlock module. The high 8 bits is the Output status for each of the eight outputs on the PointBlock module.

The Help entry for each of those reads:

This Status bit is the OR of all possible faults for this channel.
Possible Faults:
- open load
- short circuit
- over current
- no field power

So, with no additional programming you can determine in your SLC program (and announce to the operator) that *something* has gone wrong with an output channel.

To tell the difference between a No Load fault and an Overload/Short Circuit fault, you'll have to send an explicit message to get that value.

That's a different topic, and I'll first ask to be certain you have a Series C operating system with FRN10 in your controller, which makes explicit messaging MUCH simpler than it used to be.

I see that Ken has done a much better job of explaining it that I could have.

As for the mapping I never use the auto map function and always leave spare space between nodes. I learned the hard way what happens when 6 months later you need to add some I/O to node 1

I don't know if you agree with me, but I worked with device and slc500 in the past, but once compact logix appeared in the market the problems and question like the ones on this thread dissappered.
The difference in price is minimal but it saves you a lot of effort and problems.
widelto

widelto said:

I don't know if you agree with me, but I worked with device and slc500 in the past, but once compact logix appeared in the market the problems and question like the ones on this thread dissappered.
The difference in price is minimal but it saves you a lot of effort and problems.
widelto

Click to expand...

Your point is well taken.

However, in the real world, a control project is specified by "others". This forces people like me to do the best with what we are forced to work with. On this project, I have a couple of issues. One is that the customer is supplying many of the DeviceNet items, which were spec-ed and purchased long ago. Second, the processor was spec-ed long ago, too. Lastly, this customer is doing nothing to give me feedback on what they expect to get. (But I bet if they don't like something I do, they'll let me know. I hate wishy-washy customers!)

Fortunately, my project is not too complicated. However, I have been brain-storming everything on this project. For example, I need to speculate on amswers to questions like "What should be displayed on the HMI if any node dies?

Ken Roach said:

That's a different topic, and I'll first ask to be certain you have a Series C operating system with FRN10 in your controller, which makes explicit messaging MUCH simpler than it used to be.

Click to expand...

I have a 1747-L542 series C processor with FRN 8. How could I possibly have FRN 10 when I've only had this processor a few weeks?