You are not registered yet. Please click here to register!


 
 
plc storereviewsdownloads
This board is for PLC Related Q&A ONLY. Please DON'T use it for advertising, etc.
 
Try our online PLC Simulator- FREE.  Click here now to try it.

---------->>>>>Get FREE PLC Programming Tips

New Here? Please read this important info!!!


Go Back   PLCS.net - Interactive Q & A > PLCS.net - Interactive Q & A > LIVE PLC Questions And Answers

PLC training tools sale

Reply
 
Thread Tools Display Modes
Old October 3rd, 2018, 12:11 PM   #16
Firejo
Member
United States

Firejo is offline
 
Firejo's Avatar
 
Join Date: Jun 2008
Location: Redmond, WA
Posts: 1,018
Glad to hear you’re making progress but for further testing I really wouldn’t use Modbus RTU (Modbus ASCII is OK). Just because Modbus RTU is not as forgiving as DF1 doesn’t mean that if it works for RTU then DF1 will work. Normally just the opposite. To be fair, I’m not familiar with the MDS radios but there is a fundamental difference in the way RTU and DF1 operate and that difference means that radios need to handle the packets differently.
DF1 is a straight forward 10 bit word protocol and uses a typical “start of message” character and “end of message” character structure thus the receiving device knows when the packet begins and ends. RTU uses 3.5-character gaps in the data. When the receiving device sees a gap of 1.5 characters it clears its buffer and prepares of the incoming packet.
Here’s the rub with radios. All Frequency Hopping Spread Spectrum radios produce gaps in the data stream. Most are very good at keeping things in order but there are gaps and if that gap lands in the middle of a packet the receiving device will see it and think the packet is done, see that it has failed the CRC check and toss it as garbage. It then does the same thing with the remainder of the packet because it is also only half of the original. The way to deal with this is to either read the incoming packet then reconstruct it at the other end (rather than just passing the data through) or to deploy a buffer at the receiving end so that the transmitting end has time to get all of the data through and the gaps are eliminated. The first method works but it requires a lot of processor power on both ends and adds a lot of overhead to the actual RF transmission slowing things down at the application layer. The second method is what most radios do (invented by FreeWave by the way) and also works but also slows things down. My experience (with the FreeWave radio) is that because of the added delay, DF1 becomes unhappy and while it will work, it also is more likely to produce errors. To be fair I never did figure out why but without fail whenever I’d set the radio up to work with Modbus RTU I’d start getting “Bad Characters Received” when looking at the diagnostics in RSLinx. I could get the PLC’s to talk but not as fast or error free as when I turned RTU mode off. It’s very possible that the MDS radios are using the first method and since they aren’t detecting a Modbus packet they aren’t adding the delay and if that is the case then your off and running but I would find that out or at very least run RSLinx to a PLC through the radio link and see what the diagnostics say. If RSLinx is happy then the PLC’s should talk to each other just fine.
__________________
Go Hawks!!!
  Reply With Quote
Old October 3rd, 2018, 12:13 PM   #17
Firejo
Member
United States

Firejo is offline
 
Firejo's Avatar
 
Join Date: Jun 2008
Location: Redmond, WA
Posts: 1,018
P.S. You may very well know a lot of what I just posted (no intent to insult your intelligence) but I figure a lot of other people don't know what's different about MB RTU so I went off the rails (a little).
__________________
Go Hawks!!!
  Reply With Quote
Old October 10th, 2018, 03:13 PM   #18
TheWaterboy
Lifetime Supporting Member + Moderator
United States

TheWaterboy is offline
 
TheWaterboy's Avatar
 
Join Date: May 2006
Location: State of Denial
Posts: 822
All good, no such thing as too much info here.
The reason for using Modbus was just that, timing. If it passed timing then the link is as solid as possible. The radio itself might not be happy about it in some cases, but such was not the case here. This was a licensed simplex band, not hopping.
These are Ethernet radios that encapsulate the serial stream such that the entire serial "packet" gets assembled when its is completely received, only then is it sent to the locally attached device. This process should deal with the gaps as the local radio has the entire string (or it doesn't and drops it) before it attempts to send it to the device.

I also am not involving RSLinx, the PLC's talk directly to each other. Never even occurred to me to try RSLinx over serial radio.

I had to increase RSLinx delay times to get it to even work over my cellular links because of the 300-500 ms latency. Can't imagine how bad it would be over a slow connection.
  Reply With Quote
Old October 10th, 2018, 09:40 PM   #19
Firejo
Member
United States

Firejo is offline
 
Firejo's Avatar
 
Join Date: Jun 2008
Location: Redmond, WA
Posts: 1,018
Quote:
Originally Posted by TheWaterboy View Post
All good, no such thing as too much info here.
The reason for using Modbus was just that, timing. If it passed timing then the link is as solid as possible. The radio itself might not be happy about it in some cases, but such was not the case here. This was a licensed simplex band, not hopping.
These are Ethernet radios that encapsulate the serial stream such that the entire serial "packet" gets assembled when its is completely received, only then is it sent to the locally attached device. This process should deal with the gaps as the local radio has the entire string (or it doesn't and drops it) before it attempts to send it to the device.

I also am not involving RSLinx, the PLC's talk directly to each other. Never even occurred to me to try RSLinx over serial radio.

I had to increase RSLinx delay times to get it to even work over my cellular links because of the 300-500 ms latency. Can't imagine how bad it would be over a slow connection.
I didn't realize GE/MDS had a licensed version of that radio. That's a whole different animal all together. Licensed radios are much friendlier to Modbus RTU because they typically don't break the Modbus packets apart (even without the Ethernet encapsulation).
As to RSLinx, I've not used it with that much of a delay to often but when I have I've not seen to much of a problem other than it taking forever to do anything. However it was long enough ago that it is very possible that I also had to change the delay settings to get it to work.
Having said that, the reason I've used RSLinx is that it's the same driver used by the PLC's except that you get access to a lot of detailed diagnostics data. I've used it in the past to fine tune the PLC's settings by looking at the diagnostics data to see what's happening to the data moving across the wireless link.
What this really proves is there is more than one way to skin a cat. Like I said before, good to hear you've got a handle on it and it's always good to express ideas and share experiences with others.
Thanks for posting and following up.
__________________
Go Hawks!!!
  Reply With Quote
Old October 11th, 2018, 10:24 AM   #20
TheWaterboy
Lifetime Supporting Member + Moderator
United States

TheWaterboy is offline
 
TheWaterboy's Avatar
 
Join Date: May 2006
Location: State of Denial
Posts: 822
Radios are MDS Orbit. Was more tricky to config than necessary because we have a couple locations where Store and Forward is needed. This was further complicated by having both the docs and the videos portray configurations that just didn't function the same in this radio. They worked in the SD and XS(?) models, but not this one. GE support was equally surprised but verified it on their end. I expect unannounced firmware updates will follow.

I'm gonna try RSLinx just for the experience. Thanks for chatting.
  Reply With Quote
Old October 11th, 2018, 12:24 PM   #21
Firejo
Member
United States

Firejo is offline
 
Firejo's Avatar
 
Join Date: Jun 2008
Location: Redmond, WA
Posts: 1,018
Thumbs up

Quote:
Originally Posted by TheWaterboy View Post
Radios are MDS Orbit. Was more tricky to config than necessary because we have a couple locations where Store and Forward is needed. This was further complicated by having both the docs and the videos portray configurations that just didn't function the same in this radio. They worked in the SD and XS(?) models, but not this one. GE support was equally surprised but verified it on their end. I expect unannounced firmware updates will follow.

I'm gonna try RSLinx just for the experience. Thanks for chatting.
__________________
Go Hawks!!!
  Reply With Quote
Reply
Jump to Live PLC Question and Answer Forum

Bookmarks


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Topics
Thread Thread Starter Forum Replies Last Post
Ethernet PLC to Serial Radio jfritz8 LIVE PLC Questions And Answers 8 September 6th, 2016 04:37 PM
burn ethernet pc card while connecting to ml1400 parralle with a serial cable. Jeff23spl LIVE PLC Questions And Answers 6 August 18th, 2015 02:57 PM
Serial event on ml1400 series-a scadagetco LIVE PLC Questions And Answers 11 March 30th, 2013 11:53 PM
radio shack usb serial cable rexracer LIVE PLC Questions And Answers 4 February 9th, 2012 11:47 PM
CLX - PLC5 via serial port? Vladimir LIVE PLC Questions And Answers 1 February 3rd, 2005 01:05 AM


All times are GMT -5. The time now is 09:00 AM.


.