Sign in to follow this  
Followers 0
JayFree

Devicenet to RS232 re-formatting

5 posts in this topic

Hello, I have a tool that communicates to several slave devices over D-net. The PLC is a Beckhoff, and any configuration of the PLC is inaccessible by anyone except the OEM of the tool. We want to swap out 2 slaves (pressure controllers) for another pressure controller but there is not a drop-in replacement that can do what we need it to do. The only controller capable of what we need communicates through RS232. We want to adjust and monitor the pressure setpoint and measurement with our standard HMI, through the D-net network. Therefore I need to convert the D-net signal into a usable command and send it via RS232 to the controller. The controllers manual lays out how the messages needs to be formatted when coming in from the RS232. I purchased this unit: https://www.mksinst.com/f/rs232-to-devicenet-gateways

That can take in D-net and out put RS232, and can be configured to do reformatting of the signal but I need to know what the signals looks like coming through our D-net so I can then take the relevant pieces and then add/remove the rest and send it along through the RS232 to our new controller. I am in the semiconductor world and was told that the communication between master and slave is "standard Group 2 only" protocol, and I have searched to find out what this means for our specific devices but have come up empty. Is there a way read the data stream with some software or secondary device or is there an example of the sequence of data that is standard to "Group 2 only"

I have found some guides online but I am not int he networking world and I dont quite understand them (see attached).

 

Thanks!

v1Ch4.PDF

Share this post


Link to post
Share on other sites

Unfortunately, without access to the DeviceNet master configuration, what you want to do is either impossible or very difficult.

While that MKS device is very useful (and a classic;  I wrote some of the first A-B technotes using it in 1999) it has a slave data layout that's built for ASCII string transfers and almost certainly doesn't match the pressure controller's data layout.    

Imagine you're exchanging eight 16-bit words of data.   The "group 2 only slave" standard just means that the data gets from Point A to Point B every X milliseconds.   It doesn't say anything about what each word means or does.

There's also the issue of electronic keying;  most master devices check the Identity Object and won't connect to a device that doesn't match what they expect. 

If I was going to take this on, I would need a DeviceNet slave whose ID object could be modified, and which is custom programmable on the serial slave side.   The Hilscher NT100-DN-RS might do the job, or a Red Lion DSPSX with a DeviceNet slave.    I have used both of those devices but never tried to change their Identity Object.

To analyze the network, you would need either a raw CANBus analyzer (and a very strong DeviceNet background) or a more sophisticated tool like Frontline Test Equipment's NetDecoder.

Compared to paying the OEM to modify their program to work with a different pressure controller, how much effort and time can you put into this ?

1 person likes this

Share this post


Link to post
Share on other sites

Followup:   I got out my Hilscher SyCon.net configuration software and created a new project for a NetTap NT100-DN-RS, which is a DeviceNet Slave on one side and a programmable serial device on the other.

The Configuration screen does let you change the default ID object Vendor, Type, Code, and Revision from representing a Hilscher NT100 gateway to anything you wish.  So that would let you get around the electronic keying issue.    You can set the I/O connection size to anything you like, so you could emulate the data size of the existing pressure controller.

I have never used Hilscher's NetSCRIPT engine to program a serial interface.   That might or might not be a way for you to use the NT100 as a gateway for this application.

 

1 person likes this

Share this post


Link to post
Share on other sites

Disclosure:  This is the sort of thing I do for a living, but obviously it's a pretty expensive thing to contract out.   I'm happy to discuss it directly.

1 person likes this

Share this post


Link to post
Share on other sites

Hello Ken,

 

Thank you for the thorough reply. I have been working on this along with many other things (Im actually the process engineer on my tool, not anything to do with hardware or networking but this seemed like a fun challenge haha) but have recently gotten back to it. I kind of came to the conclusion that you did though, that this will be exceedingly difficult and maybe not worth it. We really didnt want to involve the OEM because were running kind of a skunk-works operation, so the less they know the better. But eventually we may inform them and ask them for the upgrade. Although I also realized that the upgrade may be difficult/expensive as well, since our Beckhoff PLC doesnt have a serial output, and one cannot be added in the field easily.

That said I did come up with a work around that cost very little money and gives us half of the functionality we need: We have a spare ethernet connection on our Beckhoff PLC and I uploaded an application to run in parallel that just sniffs out the signal of interest going out to the D-net slaves, using the device ID. Anytime the pressure setpoint of that device is changed, this program receives the new value, scales it, puts it into the necessary syntax for our serial devices then outputs it via the spare ethernet cable. I then have an ethernet to serial gateway that just runs the message straight through to the pressure controller. I tested it yesterday and it worked great. So now I am able to set the pressure using the HMI to our new pressure controllers. I just leave our old pressure controller connected to the D-Net so the tool is none-the-wiser. The only problem is that I dont get the feedback that the pressure has reached the setpoint, since I cant figure out how to send the signal from our new controller back into the D-net data stream, especially since its polling and it would get overwritten by the value from our old pressure controller immediately. But for now I got what I needed. I may still work on the D-net to serial gateway in my spare time, or just let the OEM work on it.

 

Anyway, I appreciate the insight. I had barely heard of device net before taking this on and I learned a lot. If youre willing to speak directly (free of charge obviously haha) I would be interested in hearing your thoughts.

Edited by JayFree

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0