Has anyone used explicit messages on DeviceNet? I am using a SLC-500 scanner module, firmware 4.26, and I am trying to talk to a GE-Fanuc S2K
Series Stepper controller. I have a block set up that I am moving into the M-File. Object 4, Instance 0x380, Service 0x10, Attribute 3. This is supposed to set a block of floating point registers. When I execute the COP command to move the data into the M0 file, and then COP the response out of the M1 file, I get a status 01 (successfully completed) on the matching TXID, but the registers are still 0....

My data block is (in hex):

0101 - TXID = 1, Command = execute
0016 - Port = 0, 16 bytes in length (hex)
1002 - Service Code 10 (Set Data), MAC ID = 2 (device net address 2 is
the drive)
0004 - Class 4
0380 - Instance 380
0003 - Attribute ID = 3
0000
0028 - 40 Decimal
0000
0014 - 20 Decimal
0000
0003 - 3 decimal
0000
0014 - 20 Decimal


Which should set VF1 = 40 (Floating point Variable #1), VF2 = 20, VF3 = 3, and VF4 = 20. Instead, they all remain unchanged....

I set them to non-zero values before running the block, so I know it isn't the 0000 words that are causing my trouble...

I am able to communicate to the device using implicit msgs which allow me to change 1 value at a time, but I would like to be able to do more than that.

Thanks for any help. A block of ladder would be best, but any suggestions would be appreciated.


--Joe Jansen

 

A Follow up:

Apparently, limits on the DeviceNet scanner module from Allen Bradley make this transaction impossible. The object that I am trying to use in the drive requires (32) 4 byte words of data for writing or reading. Because of the memory architecture of the SLC, and the fact that everything has to go through the M files, you are limited to your header plus 58 bytes of message data. And as everyone knows, you can't fit 128 bytes of stuff in a 58 byte bag! ;^> If any list members from Rockwell can confirm or deny my
finding, I would appreciate it.

I have been able to read and write individual data points using explicit messaging to this drive, as posted on the other thread. I have also found that some of what I assumed was vendor specific is not. Although I am
unable/unwilling to pay the $300 "copying cost" for the device net spec, it appears that the service codes (0x10 and 0xE0) are standard for single point write / read functions, respectively.

I will try to get something written up for posting to PLC Archive in the next few days, however, it may still end up being fairly vendor specific, because of the object model layout in each component. Hopefully something can be made that can be cut - and - paste - ish....

If anyone wants to ask questions / post comments on this or the other thread, I would appreciate the feedback.

--Joe Jansen

 

Joe,

Crossed posts !

You're right that the size of an explicit message that can be sent by the 1747-SDN is smaller than the DeviceNet maximum because of the M0/M1 method
to get data from the SLC backplane into the transaction buffer. I guess I could have economized on words.....

Other A-B DeviceNet scanners based on other controller architectures are able to send larger messages; the ControlLogix 1756-DNB and the 1788-CN2DN can send full-length 255 byte explicit messages, and the 1761-NET-DNI might be able to as well. I have not gotten to use the new 1769-SDN yet.

As I think you've seen with the S2K motion controller, you'll probably have to use the Class 67, Floating-Point Variable class of objects to send these floating-point variable values one at a time.

Some DeviceNet interfaces allow configurable assemblies that can be complex to set up, but allow you some flexibility to decide what to access as an Assembly via explicit messaging or I/O messaging (the A-B PowerMonitor 3000 is like that). Some have less flexible but more simple implementations. I've seen this some with products based on SST's universal fieldbus
interface module, where you just get several very large assemblies.

My favorite free reference document was written by Rockwell's Julian Fielding and Rod Shearer and can be found on the www.ab.com/support
knowledgebase in the DeviceNet category as Document 10426, "DeviceNet Basics of Explicit Messaging".

I think you'll find that most DeviceNet products have a limited number of Services they support via explicit messaging. At the risk of giving away Appendix G, here are the names and codes of the Common Services:

00 Reserved for future DeviceNet use
01 Get_Attributes_All
02 Set_Attributes_All Request
03 - 04 Reserved for future DeviceNet use
05 Reset
06 Start
07 Stop
08 Create
09 Delete
0A-0C Reserved for future DeviceNet use
0D Apply_Attributes
0E Get_Attribute_Single
0F Reserved for future DeviceNet use
10 Set_Attribute_Single
11 Find_Next_Object_Instance
12 - 13 Reserved for future DeviceNet use
14 Error Response
15 Restore
16 Save
17 No Operation (NOP)
18 Get Member
19 Set Member
1A Insert Member
1B Remove Member
1C-31 Reserved for additional DeviceNet Common
Services

I don't know the GE S2K at all but from by brief reading it looks like a very capable DeviceNet interface, but mostly uses the Get Single and Set
Single services. Because it is UCMM capable I'd be attaching a PanelView.....

Good luck on your project,

Ken Roach
Technical Specialist
Rockwell Automation / Seattle

 

Joe,

You certainly didn't choose a simple device to test your chops on with Explicit Messaging; the S2K motion controller appears more sophisticated
than many other products that implement a DeviceNet interface.

What this might be is that the 1747-SDN has a 32 word (64 byte) transaction buffer (module file words M0:x.244 through M0:x.255), so with a six-byte transaction header, that leaves 58 bytes left for the message body. With six bytes taken up by the Class, Instance, and Attribute, that leaves 52 bytes of message data.

The S2K motion controller has 192 separate assembly object instances, each of which contains 32 variables of 4 bytes apiece.... so they're each 128 bytes long. Because the 1747-SDN can only send 52 bytes of data I don't think it can read or write to these large assemblies.

I think you'll find that the M1 buffer contains the error code 0x13 as the response from the S2K, meaning "too little data". You might be able to
recreate that with the Class/Instance/Attribute editor in RSNetworx for DeviceNet.

I also noticed that your outgoing data was meant for floating point registers but wasn't in IEEE 754 single-precision format. I found a clever site on the Web for converting to hex from floating-point: http://www.markworld.com/showfloat.html. Remember that DeviceNet encoding says you send the least significant byte first.

So, if the 1747-SDN can't write to this object, how do you accomplish your application?

The S2K doesn't appear to support the "Set Member" service (an alternative to Set Attribute Single when you're dealing with Assemblies) so you'll probably have to send individual messages to Class 67, the Floating Point Variable class in the S2K controller. Not as elegant as writing an
assembly, but workable.

Good luck,

Ken Roach
Technical Specialist
Rockwell Automation / Seattle
[email protected]

 

Ken,

Thanks for the very informative post. First, just a point of clarification, I believe you stated at the end of the post that the PanelView was UCMM capable, is this true? For which PanelViews? the whole family? Are they any future plans for the PLC scanners to be UCMM capable?

Also A/B is releasing a DeviceNet scanner module for the MicroLogix. Will it be more like the SLC500 scanner and have smaller than perhaps desired explicit message capabilities or will it be more like the ControlLogix scanners?

Thanks for the help.

Best Regards,

Nick Pirog
CPU Automation, Inc.
Voice: 978.692.5404
Fax: 978.692.8844
email: [email protected]
web: www.cpuauto.com