tag:blogger.com,1999:blog-352596392024-02-06T21:11:49.842-06:00Lynn's Industrial Protocols over IPDiscussing my adventures in "IP-Enabling" commercial devices that don't always appreciate being liberated from serial or Ethernet. I have been Ethernet-enabling serial devices for over a decade. However my current job involves putting Ethernet devices up on cellular (as in cell-phone) machine-to-machine data plans. I currently have a public demo site with with Rockwell, Modbus, GE, Siemens, DNP3 and other industrial PLC/devices up on cellular.Lynn August Linsehttp://www.blogger.com/profile/01534730541144544922noreply@blogger.comBlogger71125tag:blogger.com,1999:blog-35259639.post-68894959787525444332015-10-16T10:34:00.000-05:002015-10-16T10:34:08.835-05:00Revival and LTE saves the Industrial Cellular WorldFor a long time, I have been out of the industrial cellular scene - laid off by one employer who felt my industrial focus was not useful in the modern world, and hired by a new employer who disagreed.<br />
<br />
GPRS began to vanish from usability 4 years ago, and despite Verizon's "promise" that 1XRTT will survive for eternity, all sane folk understand that eventually, the cell towers need to focus on the MOST band for the BUCK.<br />
<br />
LTE is a unique opportunity, as for once the entire cellular world is focused on a single HW and radio spec. While LTE tends to highlight uber-speed cellular (like 400Mbps/sec), there is of course efforts to support the low-end, the sub-1mbps tank gauging solutions.<br />
<br />
Some of you may have heard of the LTE 'CAT' ratings, such as CAT 6 or CAT 1, CAT 1 is targeted at devices needing less than 10mbps, and a future CAT 0 less than 1mbps. I believe a key concept to understand that people who call GPRS or 1XRTT 'cheap' fail to understand that ultimately, it is how many paying customers can 'pay' for data in one instant that matters. So eventually, cellular data technology which allows MORE customers to send tiny amounts of data in less time benefits the cellular companies greatly.Lynn August Linsehttp://www.blogger.com/profile/01534730541144544922noreply@blogger.com0tag:blogger.com,1999:blog-35259639.post-16978618636834573722013-05-14T11:57:00.001-05:002013-05-14T11:57:07.111-05:00Adding GPS to a GOBI 3000 cellular module<h3>
GOBI 3000 Cellular Module</h3>
<br />
Digi products such as the ConnectPort X4 or WAN 3G which support the GOBI 3000 cellular module include the ability for direct GPS support. However, without a special antenna, you will find the signal weak and the GPS only semi-reliable. This may be good enough for a static device which never moves, because as long as the device can get a signal once within the first few days, then you'll know where it is.<br />
<br />
However, most of Digi's GOBI-enabled products include two SMA connectors for two cellular antenna. CDMA can directly use two antenna, but GSM only uses one, ignoring the second. You can remove one of the two antenna, installing a PASSIVE GPS antenna with a male SMA connector. You'll still need a clear view of the sky.<br />
<h3>
Manual Position</h3>
Don't have a clear view of the sky? Don't want to use a special antenna? Most Digi gateway allow you to manually enter a static position. For example on the Digi ConnectPort products, you can enter the <b>latitude </b>and <b>longitude </b>manually on the <b>Configuration > Position</b> web page.<br />
<br />
You can obtain the information from a cell phone - sadly, most mapping apps show you a Google Map, but not the coordinates. On my Andorid devices, I use Yigiter's "Sensor Data Monitor" app (github.com/yigiter) as it gives me the raw GPS information in real-time.<br />
<h3>
USB / Serial Modules</h3>
Alternatively, many of the gateway (for sure any of the ConnectPort with a host USB port) can support some USB-based GPS units such as the USGlobalStat BU-353 (available at amazon.com).<br />
<br />
Some of these gateways also support RS-232 models, which is listed under the <b>Serial Profiles</b> as GPS.<br />
<br />
<br />Lynn August Linsehttp://www.blogger.com/profile/01534730541144544922noreply@blogger.com0tag:blogger.com,1999:blog-35259639.post-49360527540407510792013-03-29T12:34:00.002-05:002013-03-29T12:38:04.107-05:00Be Careful with 'Assisted GPS'Many cellular modules have GPS capability, and support up to 3 modes:<br />
<ol>
<li><b>Standalone (no network assistance)</b>: the hardware tries its best with GPS satellite signals captured through the cellular antenna path. Depending on your antenna, the signal could be difficult to obtain and hold, but it won't add anything to your cellular data costs. <i>A fix might take as long as 12 minutes after power up or gaining clear sky view.</i></li>
<li><b>Mobile-based (network assisted)</b> or MSB: again, the local hardware is calculating the position, but obtains various data files <i><b>by billable network traffic</b></i>. In MSB, the hardware must detect viable satellite packets and the network help is primary to speed up the initial fix, plus help when fewer satellites are visible to the device.</li>
<li><b>Mobile-assisted (network calculated)</b> or MSA: is like MSB, but will likely have more billable network traffic. In this case, the mobile device literally forwards corrupt GPS satellite packets and other information to a network-based server, which (over-simplified) can use pattern-matching with good packets supplied by other GSP-MSA devices in your neighborhood. The network server literally offers error-correction with the very worst of satellite conditions.</li>
</ol>
The problem is that the <i><b>billable network traffic</b></i> amount is pretty weakly defined. Some of the network traffic is free, while other traffic is billable.<br />
<br />
Now an example: I had a Digi ConnectPort X4 IA with a <a href="http://iatip.blogspot.com/2012/08/one-device-for-both-gsm-or-cdma.html" target="_blank">Gobi3000 cell module</a>. An early firmware incorrectly allowed the cell module to default to GPS active in MSB mode, which wasn't a huge problem with I had the Gobi module configured for GSM/AT&T, as I had a good cell signal in my odd inner-corner office. I have been told the Gobi 3000 'ephemeris' data file & related data is about 40K, and is loaded after a cell module restart, and then refreshed once a day (I was told by word of mouth only!) <br />
<br />
However, after 6 months of happy GSM operation, I reconfigured that unit for CDMA/Verizon to test some CDMA issues, and at my desk the CDMA signal is a much worse than GSM. A few days later I started getting '<i>usage alerts</i>' from my carrier warning that my daily limit of 100K was being breached. Some investigation lead me to discover that my 10MB per MONTH cell data plan was now seeing nearly 8MB per DAY!<br />
<br />
Fortunately, I asked a fellow engineer about this, and he'd seen the problem at a large customer site. Apparently, the AGPS subsystem in my unit was failing to fetch the ephemeris data file from Qualcomm's web site, and retrying quite aggressively. This retry was creating the 8MB of unwanted data every day for enough days that I began seeing the alerts!<br />
<br />
<b>Solution?</b> Well, technically I didn't even need GPS, plus even if I did, since the unit runs 24/7, the faster initial fix wasn't of much value. My solution was to set GPS to standalone mode. In the end, the overage cost me about $34. Without the alert, I would not have detected the overage until my bill arrived, and then likely would have seen (at my $2/MB overage charge) about $500. Image if I had 100 units doing this for the same month!<br />
<br />
<b>Moral of the story</b>: Be very deliberate about GPS use within a cell module; make sure the mode selected is correct, or even turn it off if you have no need for it. <i>Of course, also make sure your usage alerts are enabled at your carrier!</i><br />
<br />Lynn August Linsehttp://www.blogger.com/profile/01534730541144544922noreply@blogger.com0tag:blogger.com,1999:blog-35259639.post-57789944576146924992013-02-06T15:23:00.001-06:002013-03-29T12:42:26.750-05:00 The future of GPRS (update)In May 2012 I created a blog entry on <a href="http://iatip.blogspot.com/2012/05/future-of-gprs-and-industrial.html" target="_blank">the future of GPRS and Industrial Automation</a>, so here is an update for February 2013.<br />
<br />
First, AT&T has officially announced its shut down of 2G / GPRS will be complete by the end of 2016.<br />
<ul>
<li>Why? To free up radio bandwidth for 4G technologies, which makes much better use of that scare resource, so more customer-bang for less-bucks</li>
<li>What does this mean? Between now and then, customers using GPRS will increasingly suffer more and more problems. AT&T officially says GPRS customers with problems can contact AT&T and they will try to sustain suitable GPRS support, however I've already heard from customers who say the answer from such contact is "Sorry, in your situation, you'll need to switch to 3G".</li>
</ul>
Second, even if AT&T is trying to maintain existing GPRS service,<b><i> they are unlikely (or certainly NOT?) adding new GPRS hardware to towers</i></b>. For example we had one customer in northern Minnesota who checked with AT&T, confirmed AT&T had home-network service in an area, but upon equipment installation, it turned out there was no GPRS support - the AT&T towers in that area where NEW, so did not have any GPRS hardware. This customer could not use their six existing GPRS-only products, instead they had to buy six new sets of 3G cellular hardware.<br />
<br />Lynn August Linsehttp://www.blogger.com/profile/01534730541144544922noreply@blogger.com0tag:blogger.com,1999:blog-35259639.post-58021644247444420572012-10-25T11:45:00.002-05:002012-10-25T11:45:23.517-05:00Controlling Overages on Your Cellular PLC AccountOver the years, I cannot count how many irate customers I've heard of who scream "We expected a $50 bill last month, but it was $3000!"<br />
<br />
Sadly, it is their own fault, not mine, not the maker of the cellular device. <br />
<br />
They are at fault for NOT making use of the tools their cellular carrier provides - or they have the WRONG carrier if the carrier lacks such tools! <b><i>Any good cellular carrier must allow you to set up daily limits, which cause an email or text message to be sent if breached.</i></b><br />
<br />
For example, this week one of my $14-per-month devices was on it's way to cost me $182 in overages. What saved me? <span style="font-size: small;"><b><i>The right tools doing the right job!</i></b> </span><br />
<br />
My cellular devices are handled by <a href="http://www.koretelematics.com/" target="_blank">Kore Telematics</a> and I make proper use of the tools which they give me. The device in question has a 10MB account, yet I normally see from 50-80KB of traffic per day, which is 2-3MB per month. Therefore I turn on 2 alerts within my Kore Telematics web portal - I am warned if the device uses more than 100KB in a single day, or if it is on track to use over 3MB per month. It recently did so. When I received the email alert, here is the DAILY summary, where I have circled the start of the offending days. <br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEih4KtaLDgFJoRctOgaXxx1GatpdiUuE29-4x0ob0NAfytQQNZaCcg51ykXkaFVPHYm1yo7IHEm-vDWRUomcQIc-QRSlNkP_rtD3_uturX0GMLLW02m2eRe8U1v0D-pttP_iV8y/s1600/kore_daily_alert.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="197" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEih4KtaLDgFJoRctOgaXxx1GatpdiUuE29-4x0ob0NAfytQQNZaCcg51ykXkaFVPHYm1yo7IHEm-vDWRUomcQIc-QRSlNkP_rtD3_uturX0GMLLW02m2eRe8U1v0D-pttP_iV8y/s320/kore_daily_alert.jpg" width="320" /></a></div>
Oct 21st had 1168KB of traffic, with over 1000% too much. I had accidentally enabled a function within the device which was creating traffic I neither wanted nor valued. The 1.168MB listed is actually only for 2/3rds of the day, so a full day of traffic would be closer to 2MB, and clearly my 10MB cell plan can't sustain 2MB per day every day of the month! <br />
<br />
I turned off the offending feature, and my usage will drop back to the expected range.<br />
<br />
Here is the Kore monthly summary, which is estimating the monthly total.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7aE6vAM_ELjTt6eWQ-4J5HPQrW9ny7R683mMSVn2TKAvrEit8GaeuD1sQJmjVJsgdO3Ka7CIAXVSN5Mcly9ytdBffJsMq2gdG4dGCtxiEkgsAJxIda-9aKd5tFrEzraSyH1tZ/s1600/kore_monthly_alert.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="197" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7aE6vAM_ELjTt6eWQ-4J5HPQrW9ny7R683mMSVn2TKAvrEit8GaeuD1sQJmjVJsgdO3Ka7CIAXVSN5Mcly9ytdBffJsMq2gdG4dGCtxiEkgsAJxIda-9aKd5tFrEzraSyH1tZ/s320/kore_monthly_alert.jpg" width="320" /></a></div>
<span style="font-size: large;">The What-If:</span><br />
Now, consider what would have happened if I had NOT seen this alert. There were 10 days left in October, so I'd have an extra 20MB of traffic on my 10MB/month cell plan - so probably 13MB of overage since I have a 7MB 'buffer' to begin with (I expect 3MB of 10MB to be used). On my 10MB plan, I pay $7 per MB for overages. So 13MB of overage in October would cost me $91.<br />
<br />
However, I would not have seen the cellular bill until the 10th or 11th of November, so another 10 days and 20MB would have already been logged in the month of November. Had I noticed the bill when it came and fixed the problem on the 11th of November, then I still would have had roughly a $91 overage on the November bill (20MB + 3MB - 10MB = 13MB).<br />
<br />
<span style="font-size: large;">Moral of the Story:</span><br />
<br />
Make sure your cellular carrier gives you access to usage alerts - and use them!<br />
<br />Lynn August Linsehttp://www.blogger.com/profile/01534730541144544922noreply@blogger.com0tag:blogger.com,1999:blog-35259639.post-694728136809750862012-08-06T15:25:00.001-05:002012-08-07T08:09:45.739-05:00One Device for both GSM or CDMACan you have one cellular device which works with AT&T, T-Mobile, Verizon, Sprint and others? The answer is: Yes.<br />
<br />
I have begun cellular tests of new units of Digi ConnectPort X4 and Digi TransPort WR21, both of which include a GOBI 3000 cellular module. This means if I select AT&T and reboot, it 'converts' the radio to use AT&T compatible frequencies and firmware, while if I select Verizon or Sprint, it 'converts' to work with those networks.<br />
<br />
Okay, what is the catch?<br />
<ol>
<li>Modest cost increase. I'm not sure what, but the GOBI module requires a fairly large FLASH to hold multiple firmware images, plus special radio hardware.</li>
<li>Slower reboots - so say some customers. Since the cell module has more software-controlled hardware, it does take longer to start up. I have not done any testing here, but eventually I will produce some numbers.</li>
</ol>
The carrier change goes surprising easy - one just selects AT&T, Verizon, Sprint (etc) on the mobile configuration web page and reboot. That is it. <br />
<ol>
</ol>
<br />
<a href="http://ftp1.digi.com/support/documentation/qn301_gobi_3g_carrier_conversion_r2.pdf" target="_blank">Digi Support Documentation: Gobi 3G Cellular Carrier Conversion Guide</a><br />
<br />
Digi is also working on a Python script which can be used with a 'test unit' activated on multiple networks (for example, the 3 big ones). The script can be run for a few days and records various statistics - radio strength, connection delays, upload throughput. This will be very useful for a customer with perhaps 100 sites to install, and they have reason to believe that no single carrier will be available at all 100 sites.Lynn August Linsehttp://www.blogger.com/profile/01534730541144544922noreply@blogger.com0tag:blogger.com,1999:blog-35259639.post-57476976587101035682012-07-29T12:00:00.001-05:002012-07-29T12:00:39.506-05:00Holding open TCP sockets on cellularA reader asked me to offer suggestions for keeping sockets open long-term - for example, you might open a connection to a status/event ASCII printer port and then on the host collect events.<br />
<br />
First, let me say up front that <span style="font-size: large;">it will be impossible to ever see such a cellular-based TCP socket remain open 'forever'</span>, which in this context is say a year or more. Cellular just does not work that way.<br />
<br />
Although not a scientific response, after my 6+ years of work with cellular, I will guest-imate that the longest connection I have ever seen is probably about 20 days, and that the most common pattern is to be connected a few days (2 to 5), then a day with several disconnects and reconnects. If your application cannot function in this scenario, then do NOT use cellular.<br />
<br />
Things which hinder long-term socket opens:<br />
<ul>
<li>Environmental dynamics: for example a rain storm will interfere and drop signal quality.</li>
<li>Load Sharing: the bottom line for cellular carriers is always "<i>Make the most users as happy as possible</i>", with a bias towards humans with smart-phones. This causes:</li>
<ul>
<li>All users share bandwidth, so the more users are active, the less throughput and 'service' any of them receive.</li>
<li>Since most human interaction is fast bursts of one-shot, always give priority to new sockets. The longer your 'session' exists (aka: your TCP socket is open), the more likely it is to be dropped during high tower loads.</li>
</ul>
<li>Time-Of-Day issues: many cell towers literally shift (or point) in different directions during the day. For example, when highway traffic is light they may point out over a residential or industrial area, but during heavy traffic they shift towards the roads. Seems weird, but the goal is to maximize the bandwidth usage, so the tower always tries to point to the most active users.</li>
<li>The 5M-KOD (5-Minute Kiss- Of-Death): All idle TCP sockets should be assumed to vanish after being idle for 5 minutes. You should always use TCP keepalive set to about 4 minutes, 50 seconds.</li>
</ul>
Cost considerations:<br />
<ul>
<li>Most carriers now round up per socket, per hour. Why do they do this? Because they can! And because they bill in somthing called 'units', which are 1K blocks. So if you look at your bill you'll see that a certain session started at for example 8:12AM, ended at 1PM and includes 47 units of data.</li>
<li>This means if you hold 1 socket open for 1 hour, you will suffer at most a 1K data round-up per hour (or 24K per day).</li>
<li>This means if you instead open a new socket every 5 minutes, then you open 12 'sessions' per hour and you will suffer at most a 12K data round-up per hour (or 288K per day).</li>
<li>In both cases above I use the 'at most' phrase and do not attempt to average anything. if your data is random, then fine - worst case is likely 1/2 of what I state, but unfortunately most industrial systems are moving predictable data each time. So if you just happen to move 1 byte 'too little' each hour, then you'd get a wonderful 1 byte round-up - but if your standard size makes you 1 byte too large, then your roundup is always 999 bytes per hour.</li>
<li>Opening/Closing a socket includes from 500 to 1000 bytes of overhead.</li>
<li>A TCP keepalive includes about 100 bytes over overhead, however MOST TCP stacks only send the keepalive if the line is idle.</li>
<li>Never poll at a once-per-5 minute rate! If you really want once per 5 minutes, you really need to poll at for example once per 4 minutes and 45 seconds. You must stay away from the 5M-KOD like the plague, or you risk all kinds of weird cell network issues. Again, I will be unscientific, but state that since many vendors are involved in your link, you have a huge race condition at 5 minutes where part of the link is already down and part is still up for the moment. And since the cellular system is NOT IP based, this increases you probability that the cellular link appears up to your cell module, yet is really broken & unusable.</li>
</ul>
Suggestions to create a better TCP socket experience:<br />
<ul>
<li>Use UDP/IP when ever you can! It has been shown in my own tests to cot up to 85-90% of your data costs! </li>
<li>Accept that you cannot keep the TCP socket open forever. If you wish to (for example) have a Dynamic IP and manually program the host to use an IP which changes each time the cell link drops - this is just not feasible!</li>
<li>Ask, do you really need a socket open all the time? My own tests have show that if you expect data less than once per 30 minutes you are probably better off to open/close the socket between uses. The trade-off is the data cost to close/reopen the socket (plus the 'session round-up') verse the TCP keepalive required faster than once per 5 minutes to keep the socket healthy.</li>
</ul>
<br />
<br />
<br />Lynn August Linsehttp://www.blogger.com/profile/01534730541144544922noreply@blogger.com0tag:blogger.com,1999:blog-35259639.post-75609219043120775262012-05-25T10:08:00.003-05:002012-05-25T10:09:40.723-05:00The future of GPRS and Industrial Automation?I have been working more on local RF mesh than cellular, so my blog has been quiet.<br />
<br />
However, users should be aware that GPRS in on the way out. AT&T (and others) will swear up and down that they still fully support it, however we have customers reporting that their mobile (truck) based systems using GPRS are finding more and more dead-spots.<br />
<br />
I agree that GPRS is not dead. However, before investing in a GPRS-only cellular devices, consider the facts and your needs:<br />
<ol>
<li>AT&T stopped certifying new non-3G devices years ago.</li>
<li>AT&T has been rumored to be reallocating air/RF-space away from GPRS to 3G technologies because the 3G makes much better use of this scarce resource - so more happy customers with 3G than GPRS. </li>
<li>AT&T claims to have fully adjusted their pricing so that 3G is comparable to GPRS - they were forced to do this because A) they don't want more/new GPRS users, but B) huge customers were still going GPRS because it was cheaper. So I have been told this is less true now.</li>
<li>AT&T claims to not be killing GPRS ... yet. </li>
</ol>
<br />
So if you roll the above facts together, I speculate that what is happening is that more GPRS devices are being squeezed into sharing less bandwidth, so whereas before a dozen GPRS devices might share 5 or 6 units of 'resource', now they might need to share 1.<br />
<br />
If true, this means that the devices have lost bandwidth in recent years, so are now running on a fraction of what they had a few years ago. The net result is that devices which upload say 200 bytes a day likely won't notice a difference, however anyone trying to open a fancy web page might discover the task nearly impossible.<br />
<br />
GPRS runs at from 9600 to 80kbaud, but devices are allotted 'slots', so think time-division-multiplexing & other forms of fair sharing. So if a tower offers 28.8kbps service to one GPRS device, and 3 more GPRS devices come online, then in theory they all may see closer to 7kbps throughput. So the device sending a single small UDP or SMS packet won't notice, while the device which requires successfully sending 350 large packets end-to-end will notice a huge drop in performance, and if the client/server have 'task timers', they may discover that they can no longer complete the task before the connect drops or task-timers expire.<br />
<br />
So bottom line - AT&T has not yet killed GPRS, but they clearly have it lined up against the firing-wall! People who have tiny data needs can still safely use GPRS if their ROI window is fairly short-term (a few years). However, people wishing to <i><b>EVEN OCCASIONALLY</b></i> move a 1/2 Meg file for firmware update or diagnostics may find GPRS less and less usable. Those who plan to routinely move even dozens of K-bytes of data might begin to see reliability problems, so should move to 3G devices.Lynn August Linsehttp://www.blogger.com/profile/01534730541144544922noreply@blogger.com0tag:blogger.com,1999:blog-35259639.post-62611149017751431742010-06-02T12:03:00.000-05:002010-06-02T12:39:44.458-05:00Increasing cellular robustness for ModbusA customer of ours is creating a custom Python program in one of Digi's cellular gateways. The gateway uses Modbus/RTU to poll a flow-computer, then based upon a time cycle or abnormal events, the gateway uses HTTPS and XML to push data up to a central server.<br /><br />They have noticed that at times the gateway has trouble connecting to the server for hours at a time, so wondered what the best solutions are to increase success. Their code buffers the data, so no data is lost.<br /><br />The customer had asked about using a Windows PC to PING the remotes, but I don't think that will help.<br /><br />Mobile-originated (meaning the gateway calling out to cellular) will be more robust than mobile-terminated (meaning Windows calling remote). Therefore the best solution will be for the cellular gateway to work a bit harder to connect out.<br /><br />First, a few technical details:<br /><ul><li>Most IP-based cellular devices maintain a full-time IP connection. However, the cell tower 'parks' the device when it is not talking, which means the device loses any radio channels and can only talk after requesting and WAITING for reallocation of bandwidth. And no, there is no way to compel your cellular provider to preallocate full-time a scarce radio resource to a device that is not paying $4000 per year for full-time data movement.</li><li>This means there is always a delay when a device starts to send data after being idle. I have witnessed this delay being up to 18 seconds long, but it could be longer. Not all TCP/IP clients expect to see such long delays in the connect/socket-open phase.</li></ul>So assuming the customer's problem is unexpected long delays causing the gateway to give up too soon, the best suggestion is to prime the pump early. Lets say your gateway sends data once per hour, so when your Python task wakes up to send data, then do NOT try to open a TCP socket right away. Instead, first send a garbage UDP/IP packet to your host, then sleep another 15 seconds. It does not matter if the UDP packet fails. You do not need to enable UDP on your host, nor watch for a good or error response. The only goal is to force the cell tower to start allocating radio bandwidth 15 seconds before your task actually tries to create your TCP/IP socket.<br /><br />This pre-allocation may solve your problem when the problem is caused by slower allocation of radio bandwidth. Since most cellular providers now round up data traffic to the 1K charger per hour, sending an extra 30 bytes per transaction should not increase costs.<br /><br />However, the problem may NOT be radio bandwidth, but authorization through a chain of roaming service providers. This is especially true for low-cost GPRS/GSM providers. Your data is passing through 2, 3 or more companies, and although they may all have agreed to allow the IP session (the PPP session) to open, one of them might drop the ball and block your data access in a way which the PPP session doesn't detect. The only way to recover is to completely flush and rebuild the PPP session - which in plan English means renegotiate with the base carrier to be assigned your IP address. It simulates a reboot of the product.<br /><br />Fortunately, Digi includes a low-level feature called SureLink, which can use a PING packet to confirm end-to-end connectivity. You can (as example) configure the Digi to PING an internet IP once per hour (or 'X' hours), then physically reboot the cellular module if access fails. This nicely forces a complete renegotiation of the PPP session, which costs you nothing.<br /><br />Just be aware that use of DNS can be costly and error-prone. A single DNS lookup can cost over 1K of data plan. For SureLink, you literally want to use a static IP as the target to minimize the overhead costs and false-negatives where things other than PPP health block success.Lynn August Linsehttp://www.blogger.com/profile/01534730541144544922noreply@blogger.com0tag:blogger.com,1999:blog-35259639.post-84388483527536763152010-04-06T10:22:00.000-05:002010-04-06T10:27:10.664-05:00Sorry about the moveGoogle/Blogger decided to change the way they interact with externally hosted blogs - probably a reaction to some search-engine abuse since blogger blog 'index' very well under Google.<br /><br />(This post is a test, plus to move down the redirect message)Lynn August Linsehttp://www.blogger.com/profile/01534730541144544922noreply@blogger.com0tag:blogger.com,1999:blog-35259639.post-86435494532962536942010-04-06T09:16:00.001-05:002010-04-06T09:48:32.334-05:00This blog has moved<br /> This blog is now located at http://iatip.blogspot.com/.<br /> You will be automatically redirected in 30 seconds, or you may click <a href='http://iatip.blogspot.com/'>here</a>.<br /><br /> For feed subscribers, please update your feed subscriptions to<br /> http://iatip.blogspot.com/feeds/posts/default.<br /> Lynn August Linsehttp://www.blogger.com/profile/01534730541144544922noreply@blogger.com0tag:blogger.com,1999:blog-35259639.post-16639141900554204032010-04-06T08:39:00.000-05:002010-04-06T08:58:30.013-05:00How Long to Obtain Cellular IP?Well, I finally have a SIM, so I can actually do cellular tests again. It is a GSM 'Capped Plan' with 20/MB of data per month for $30. The 'capped' means that even if I go over the 20MB by dozens of GB, the maximum charge will be $130. It is a truly 'unlimited plan' for that $130. What's the catch? If I hit the 'Cap' two months in a row, then the carrier either cancels the account or forces me to start paying full-rate for a normal 1GB or 5GB/mo plan.<br /><br />The 20MB is fine for me since I am testing methods to keep data small.<br /><br />My current tests have a sleep devices waking, then obtaining a cell-link. For example, I am working on a Digi gateway called an X3 (not on Digi's web site yet). The X3 can power itself down completely, using a real-time clock chip to wake it at a future time.<br /><br />I ran a test for 5 days, waking the X3 device every 10 minutes and clocked how long it too for the GSM carrier to assign an IP to the X3:<br /><ul><li>The fastest time was 23.7 seconds (half a minute)<br /></li><li>The slowest time was 97.0 seconds (1 and a half minutes)</li><li>The average time was 28.6 seconds (so most near 30 seconds, with a few long outliers)<br /></li><li>Note that there will be several seconds of CPU start-up time in there - I can only know the RTC wake-up time (which I loaded into the RTC last cycle) compared to the RTC time when the IP address is assigned.<br /></li></ul>Why is this important? Because the cellular modem consumes a LOT of power for the duration of this variable time. It is one of the variable which makes estimating battery life difficult.<br /><br />My next test will include actually doing work - probably sending a Modbus/TCP transaction to a DSL-based server.Lynn August Linsehttp://www.blogger.com/profile/01534730541144544922noreply@blogger.com0tag:blogger.com,1999:blog-35259639.post-50401294375200829912009-10-13T16:09:00.000-05:002009-10-13T16:47:16.040-05:00Cellular DNS Lookup CostI have been working with a customer using two cellular devices with a DDNS provider, so the 'Client/Master' device used a DNS name to connect to the remote 'Server/Slave' device.<br /><br /><span style="font-size:130%;">Cost #1 - added delay<br /></span>The first cost they were seeing was added time lag to open a connection. <br /><ul><li>To open a TCP socket between two idle (but connected) cellular devices requires each device to be "unparked" by their cell tower. So the client device would need to request a resource and be assigned it by the local cell tower - this can require 2 to 5 seconds. </li><li>Next, a DNS query would be sent and a response would be required. Some cellular carrier DNS servers don't seem very peppy, so this could add a few more seconds.</li><li>Then the client device would receive notice from the cell-tower control channel to request a resource and be "unparked"</li><li>Finally, after "X" seconds of delay and lag the client device would receive confirmation that the socket is open (or it might have given up to fast already & aborted).</li></ul>So using a DNS name instead of an IP Address might add a few seconds delay - which might be just enough to cause problems. The customer I am working with has a client tool with a hard-coded MAX timeout of 25 seconds, and it seems to often hit this during original socket open. So they have no trouble communicating once the TCP socket is open, but it can be difficult to get the first data packets moving.<br /><br /><span style="font-size:130%;">Cost #2 - added traffic<br /><span style="font-size:100%;"></span></span>Of course the DNS query also adds raw traffic. DNS uses UDP, and a query might be 44 bytes and a response 60 bytes. So 104 bytes extra to open a TCP socket (which can be hundreds of bytes by itself). <br /><br />Is this traffic important? Perhaps. Perhaps Not. Most cell plans today round up traffic hourly, so an extra 104 bytes for DNS and 150 bytes for a Modbus poll/response is still "1K of traffic".<br /><br />For TCP/IP, the DNS lookup would only occur for a socket open. So regardless of the DNS name Time-To-Live, you might only see this added 104 bytes once per day or month - or anytime you open/reopen a socket.<br /><br />However for UDP/IP you MIGHT see this DNS lookup for every packet. For example, a DDNS record from dyndns.org might expire in 60 seconds, so sending one 100 byte UDP packet every 5 minutes, could become 204 bytes per 5 minutes, so 2448 bytes per hour rounded up to 3K per hour or 72K per day and NOT the 49K expected.<br /><span style="font-size:130%;"><br /><span style="font-size:100%;">So while UDP/IP can save a lot of traffic cost over TCP/IP, if short-lived DNS names are required then some of UDP's savings will be lost. <br /><br />One solution is a custom application to do indirect DNS lookup. In other words, to directly lookup the DNS name within the application, then to ignore the DNS "Time-to-Live" and use only the cached IP address UNTIL COMMUNICATIONS FAILS - then do a new lookup. This is not how normal operating system DNS caches work - they literally honor the DNS server's time to live and would cause a new look up based on the 60 second time-to-live. Yet this is general safe for cellular end-devices since normally the dynamic IP only changes when the cell link is lost, so the remote IP is unlikely to change more than a few times per day.<br /></span><br /></span>Lynn August Linsehttp://www.blogger.com/profile/01534730541144544922noreply@blogger.com0tag:blogger.com,1999:blog-35259639.post-79694640535933697422009-06-10T08:33:00.000-05:002009-06-10T08:54:42.218-05:00Does Cellular 3G help your Rockwell PLC Access?<span style="font-size:130%;">In short - No.<br /></span><br />Cellular data systems are continuously being sub-optimized for the unidirectional fire-hose paradigm of web page viewing, media streaming, image viewing, email download and so on. In other words, you only see the 3G "broadband" performance when you have tens of thousands of bytes to shove in one direction.<br /><br />Actual field tests of RSLogix 5000 downloading to ControlLogix processors show that using 3G is only a few percent faster than standard technology - plus still probably slower than analog dialup. The problem is caused by RSLogix and Ethernet/IP moving thousands of small transactions in a half-duplex manner. So RSLogix downloads the PLC object by object, confirming success after each object is written. With cellular latency, each of these transactions can take up to a second to complete, so multiple 1 second by 3000 to 8000 transactions and you have your PLC download time.<br /><br />3G apologists will claim "<span style="font-style: italic;">Oh, but latency in 3G is much lower than older, coarser technologies.</span>"<br /><br />That may be, but when the rubber meets the road (aka RSLogix5000 downloads), 3G doesn't perform any better. 3G might have other value, but for most people moving data "faster" just means your data usage and the final bill racks up faster as well.Lynn August Linsehttp://www.blogger.com/profile/01534730541144544922noreply@blogger.com0tag:blogger.com,1999:blog-35259639.post-9495548510777815852009-06-06T08:32:00.000-05:002009-06-06T09:49:37.388-05:00Cellular to Redundant Rockwell ControlLogixCan <span class="blsp-spelling-error" id="SPELLING_ERROR_0">RSLinx</span> access a redundant pair via cellular?<br /><br /><span style="font-weight: bold;">Background</span><br />A Pair of Rockwell Automation <span class="blsp-spelling-error" id="SPELLING_ERROR_1">ControlLogix</span> racks with <span class="blsp-spelling-error" id="SPELLING_ERROR_2">SRM</span> Module and dual <span class="blsp-spelling-error" id="SPELLING_ERROR_3">ENBT's</span> will share a pair of <span class="blsp-spelling-error" id="SPELLING_ERROR_4">IP</span> addresses. One <span class="blsp-spelling-error" id="SPELLING_ERROR_5">IP</span> address is "the primary", and the other <span class="blsp-spelling-error" id="SPELLING_ERROR_6">IP</span> is "the backup" (if/when it is online). When the <span class="blsp-spelling-error" id="SPELLING_ERROR_7">ENBTs</span> switch role, they will issue the requisite Gratuitous <span class="blsp-spelling-error" id="SPELLING_ERROR_8">ARPs</span> to cause other local Ethernet devices (like a <span class="blsp-spelling-error" id="SPELLING_ERROR_9">Digi</span> cellular gateway) to update their <span class="blsp-spelling-error" id="SPELLING_ERROR_10">ARP</span> cache, thus comprehending that the <span class="blsp-spelling-error" id="SPELLING_ERROR_11">IP</span>-to-MAC address mapping has changed. Thus a NAT/Router forwarding to the primary <span class="blsp-spelling-error" id="SPELLING_ERROR_12">IP</span> should handle the fail-over with only modest bumps.<br /><br /><span style="font-weight: bold;"><span class="blsp-spelling-error" id="SPELLING_ERROR_13">Config</span> Details</span><br />A user desiring <span class="blsp-spelling-error" id="SPELLING_ERROR_14">RSLinx</span> (and <span class="blsp-spelling-error" id="SPELLING_ERROR_15">RSLogix</span> or <span class="blsp-spelling-error" id="SPELLING_ERROR_16">RSView</span> etc) to access a remote Rockwell <span class="blsp-spelling-error" id="SPELLING_ERROR_17">ControlLogix</span> (any RA/AB <span class="blsp-spelling-error" id="SPELLING_ERROR_18">PLC</span>) will be doing what the industry calls "<span style="font-weight: bold; font-style: italic;">Mobile-Terminated</span>" access. The user needs to arrange a cell plan which offers either a fixed <span class="blsp-spelling-error" id="SPELLING_ERROR_19">IP</span> address to target, or at least a Dynamic <span class="blsp-spelling-error" id="SPELLING_ERROR_20">DNS</span> name to target (like tk101.iatips.com or panel2.digi.com). This is NOT what you obtain with an iPhone or personal air-card data plan. Those will have private <span class="blsp-spelling-error" id="SPELLING_ERROR_21">IPs</span> which only permit outgoing connections - called "<span style="font-weight: bold; font-style: italic;">Mobile-Originated</span>". <span style="font-style: italic;">That was a buzzword lesson - expect to be asked about those two terms when you ask about cellular data plans!</span><br /><br />So once you can arrange your <span class="blsp-spelling-error" id="SPELLING_ERROR_22">targetable</span> <span class="blsp-spelling-error" id="SPELLING_ERROR_23">IP</span> or <span class="blsp-spelling-error" id="SPELLING_ERROR_24">DNS</span> name, you need a cellular router such as one of the <a href="http://www.digi.com/products/cellulargateways/digiconnectwanfamily.jsp"><span class="blsp-spelling-error" id="SPELLING_ERROR_25">Digi</span> Connect WAN family products.</a> My favorite model today is the <a href="http://www.digi.com/products/wirelessdropinnetworking/connectportxgateways.jsp"><span class="blsp-spelling-error" id="SPELLING_ERROR_26">ConnectPort</span> X4</a>, but that has large memory for Python programming, wireless mesh and other goodies you won't need to link up your Rockwell <span class="blsp-spelling-error" id="SPELLING_ERROR_27">PLC</span> (Hey, I said it was MY favorite - doesn't mean it has to be yours!)<br /><br />Note that contrary to folklore or urban legend, all cellular devices need certification to work on a system - even <span class="blsp-spelling-error" id="SPELLING_ERROR_28">GSM</span> devices. Many small suppliers get around this by including fine-print that say the device buyer is responsible to arrange such legalities, and since you (the buyer) don't read such fine print the salesperson will just say "<span style="font-style: italic;">Heck, it's </span><span style="font-style: italic;" class="blsp-spelling-error" id="SPELLING_ERROR_29">GSM</span><span style="font-style: italic;"> - so it is allowed everywhere world wide!</span>" Deal with this issue as you see fit, but <span class="blsp-spelling-error" id="SPELLING_ERROR_30">Digi</span> has more formal certs in more <span class="blsp-spelling-corrected" id="SPELLING_ERROR_31">countries</span> worldwide than any of the other industrial players.<br /><br />But back on subject, when the gateway comes up, it is assigned your known <span class="blsp-spelling-error" id="SPELLING_ERROR_32">IP</span> or <span class="blsp-spelling-error" id="SPELLING_ERROR_33">DNS</span> name. This is exactly how your home or business <span class="blsp-spelling-error" id="SPELLING_ERROR_34">DSL</span>/T-line line works. Yet when <span class="blsp-spelling-error" id="SPELLING_ERROR_35">RSLinx</span> tries to talk to the gateway on Ethernet/<span class="blsp-spelling-error" id="SPELLING_ERROR_36">IP's</span> well-known <span class="blsp-spelling-error" id="SPELLING_ERROR_37">TCP</span> port of 44818, the gateway will reject the connection as a weird attempt at hacking. You need to instruct the gateway:<br /><ol><li>to not reject the Ethernet/<span class="blsp-spelling-error" id="SPELLING_ERROR_38">IP</span> traffic on <span class="blsp-spelling-error" id="SPELLING_ERROR_39">TCP</span> port 44818</li></ol><ol><li>to instead forward it to a local <span class="blsp-spelling-error" id="SPELLING_ERROR_40">IP</span> on the Ethernet - which would be the <span class="blsp-spelling-error" id="SPELLING_ERROR_41">IP</span> of your <span class="blsp-spelling-error" id="SPELLING_ERROR_42">ControlLogix</span> <span class="blsp-spelling-error" id="SPELLING_ERROR_43">ENBT</span> (or the primary <span class="blsp-spelling-error" id="SPELLING_ERROR_44">IP</span> of the redundant pair)</li></ol>The details of how this man-in-the-middle fake-out works is fascinating (to me), but quite a pile of text. If you are interested, <a href="http://blog.iatips.com/2007/06/real-world-cellular-controllogix-plc.html">this older blog entry goes through the NAT/Router details blow by blow.</a> But bottom-line, your <span class="blsp-spelling-error" id="SPELLING_ERROR_45">ENBT</span> receives the <span class="blsp-spelling-error" id="SPELLING_ERROR_46">RSLinx</span> packet and needs to have its own Gateway <span class="blsp-spelling-error" id="SPELLING_ERROR_47">IP</span> set to the <span class="blsp-spelling-error" id="SPELLING_ERROR_48">Digi</span> gateway's local Ethernet <span class="blsp-spelling-error" id="SPELLING_ERROR_49">IP</span> address. <span style="font-style: italic;">Free hint: 9 out of 10 guys who call saying "Why can't <span class="blsp-spelling-error" id="SPELLING_ERROR_50">RSLinx</span> see my <span class="blsp-spelling-error" id="SPELLING_ERROR_51">PLC</span> through your <span class="blsp-spelling-error" id="SPELLING_ERROR_52">Digi</span> gateway?" have failed to set the correct Gateway <span class="blsp-spelling-error" id="SPELLING_ERROR_53">IP</span> in the <span class="blsp-spelling-error" id="SPELLING_ERROR_54">PLC</span>/<span class="blsp-spelling-error" id="SPELLING_ERROR_55">ENBT</span>.</span><br /><br />So assuming your gateway and <span class="blsp-spelling-error" id="SPELLING_ERROR_56">PLC</span> are setup correctly, then targeting the <span class="blsp-spelling-error" id="SPELLING_ERROR_57">RSLinx</span> "Ethernet Devices" driver (with timeouts slowed down to 30 seconds) will cause your <span class="blsp-spelling-error" id="SPELLING_ERROR_58">PLC's</span> little icon to show up. With <span class="blsp-spelling-error" id="SPELLING_ERROR_59">RSLinx</span> running, you will create up to 200MB of billable cell traffic per month doing absolutely nothing - so don't leave it active. <span style="font-style: italic;">Note that the "Ethernet/<span class="blsp-spelling-error" id="SPELLING_ERROR_60">IP</span> Driver" won't work as it requires <span class="blsp-spelling-error" id="SPELLING_ERROR_61">UDP</span> broadcast, which can't be routed over the Internet.</span><br /><br />At this point you'll say "Cool, now can I see my backup <span class="blsp-spelling-error" id="SPELLING_ERROR_62">ControlLogix</span> or a second <span class="blsp-spelling-error" id="SPELLING_ERROR_63">PLC</span>?", and the simple answer is "No." One of the realities of <span class="blsp-spelling-error" id="SPELLING_ERROR_64">RSLinx</span> and AB <span class="blsp-spelling-error" id="SPELLING_ERROR_65">PLC</span> is that the Ethernet/<span class="blsp-spelling-error" id="SPELLING_ERROR_66">IP</span> protocol is hard fixed to only the <span class="blsp-spelling-error" id="SPELLING_ERROR_67">TCP</span>/<span class="blsp-spelling-error" id="SPELLING_ERROR_68">IP</span> port 44818, and the NAT/Router can only forward <span class="blsp-spelling-error" id="SPELLING_ERROR_69">TCP</span> port 44818 to a single local <span class="blsp-spelling-error" id="SPELLING_ERROR_70">PLC</span>. The easy fix would be for Rockwell to change <span class="blsp-spelling-error" id="SPELLING_ERROR_71">RSLinx</span> to enable adding both an <span class="blsp-spelling-error" id="SPELLING_ERROR_72">IP</span>/<span class="blsp-spelling-error" id="SPELLING_ERROR_73">DNS</span> name and <span class="blsp-spelling-error" id="SPELLING_ERROR_74">TCP</span> port number - then the NAT/Router <span class="blsp-spelling-corrected" id="SPELLING_ERROR_75">could</span> forward <span class="blsp-spelling-error" id="SPELLING_ERROR_76">TCP</span> port 44818 as 44818 to the primary <span class="blsp-spelling-error" id="SPELLING_ERROR_77">ENBT</span>, <span class="blsp-spelling-error" id="SPELLING_ERROR_78">TCP</span> 44819 fixed-up to 44818 to the secondary <span class="blsp-spelling-error" id="SPELLING_ERROR_79">ENBT</span>, <span class="blsp-spelling-error" id="SPELLING_ERROR_80">TCP</span> 17256 (a random number :-]) fixed up to 44818 to an <span class="blsp-spelling-error" id="SPELLING_ERROR_81">RSView</span> panel and so on. Because the NAT/Router can restore all traffic to 44818 on the local Ethernet, <span class="blsp-spelling-error" id="SPELLING_ERROR_82">RSLinx</span> is the only tool needing to change. <br /><br />Will Rockwell ever do this? It would take a programmer half a day to do - then a few weeks to test - then a few months to document and <span class="blsp-spelling-corrected" id="SPELLING_ERROR_83">forestall</span> support headaches. So who knows. They might. They might not.<br /><br />But <span class="blsp-spelling-error" id="SPELLING_ERROR_84">bottomline</span> is a simple cellular NAT/Router can be used to talk to a pair of <span class="blsp-spelling-error" id="SPELLING_ERROR_85">ControlLogix</span> running in a <span class="blsp-spelling-corrected" id="SPELLING_ERROR_86">redundant</span> configuration - you will just be limited to seeing only the primary <span class="blsp-spelling-error" id="SPELLING_ERROR_87">ENBT</span> and the primary <span class="blsp-spelling-error" id="SPELLING_ERROR_88">IP</span> address.Lynn August Linsehttp://www.blogger.com/profile/01534730541144544922noreply@blogger.com0tag:blogger.com,1999:blog-35259639.post-81606113941738216942009-04-07T07:56:00.000-05:002009-04-07T09:16:17.678-05:00Cellular Antenna and your PLCOne of my customers is having fun with one of their own customers. My customer uses Digi gateways running a Python application to collect hourly tank levels, which are fetched by cellular once per day. The tanks hold 250-gallons of a chemical additive which is injected at a variable rate into crude oil pipelines. Small battery-powered ultrasonic level sensors (www.massa.com) push the last 8 hourly samples every few hours using wireless IEEE 802.15.4 (aka Zigbee). The end customer's goal is to forecast when the tanks need to be refilled ... and I don't mean just receive an alarm when it is running low, they literally want to plan truck routes in advance.<br /><br />Fun stuff.<br /><br />The problem is that one of the pilot sites has bad cell coverage, meaning many days the central system cannot upload the log. Of course the data eventually it all uploads since it is held for over a month. Now, never mind that this system sits down in a dry wash (a small valley), the end-user says "Hah, that's because carrier A*** stinks; we all love carrier S****." My customer does not want to mix carriers - especially since negotiated pricing between the two in question is so different.<br /><br />So remember that "coverage" for fixed RTU must be viewed differently from "coverage" for mobile uses. <br /><br />For a mobile device (or user) "coverage" is defined by the probability that a valid carrier connection will be available as the device moves around. Thus the number of towers (etc) is important, and if there is no signal in one spot, then hopefully will be one a mile or two away.<br /><br />Unfortunately, our little RTU bolted to a power pole in that gully won't be moving a mile or two ever. So in the end, "coverage" for a fixed device is defined only by the tower(s) which can be seen. So the carrier with the best cell-phone coverage might not be the best carrier to support a particular fixed RTU.<br /><br />The first step will be to move the RTU up out of the gully, which is easy since the data signals are all wireless and power can be tapped from any of the privately owned power poles. Probably carrier A*** (stinky or not) will work fine once the RTU moves. As plan B and make the end-customer feel listened to, a S****-based RTU will be placed on the same pole as the relocated A*** one. <br /><br />Could they run out a long external antenna? Sure, they could. But why bother? Put the RTU where it has a nice signal. Even in 2 or 3 store buildings we suggest customers put the cellular router up in the roof-area and run the Ethernet UTP it's 100 meters instead of trying to deal with the signal loss in long antenna cables. We even have customers using 900Mhz Ethernet bridges to link a cellular router placed where it must be placed back to the Ethernet devices which want access.<br /><br />Worst case, a directional yagi antenna could be used, however you need to understand that cell towers are routinely turned off without warning. The carriers are truly geared towards mobile users who expect bad signals in some places. Towers (or the active elements) also move. Most of the cell towers you see along the highway work like strip-malls; a company owning the tower and supplying power leases tower space to a mix of carriers. This allows everyone to be flexible.<br /><br />So prematurely locking down a cellular device to a single tower with a directional antenna can cause future problems since it will not see other weaker towers should the targeted tower be turned off or even moved.Lynn August Linsehttp://www.blogger.com/profile/01534730541144544922noreply@blogger.com0tag:blogger.com,1999:blog-35259639.post-73858251608226638292008-11-25T08:29:00.000-06:002008-11-25T09:13:56.841-06:00Ethernet/IP PCCC Service Codes<span style="font-size:130%;">Summary: the Rockwell PCCC Service Codes (or how to get a 1761-NET-ENI or Digi One IAP to send specific DF1 DST/SRC bytes)<br /></span><br />A customer had a product which acted as an Ethernet/IP originator (client) and needed to talk through a Digi One IAP to feed DF1 into a DH+ gateway. The catch is the DH+ gateway used the DF1 destination byte as the DH+ node address - and so far they could only make the Digi One IAP spit out a destination = 1. This made for pretty boring and unprofitable DH+ design!<br /><br /><span style="font-style: italic;">(Sorry: I cannot explain "How to write an Ethernet/IP stack" in a single blog entry, so this entry assumes you already have a product speaking Ethernet/IP and just want to tweak how you talk to remote DF1 devices.)</span><br /><br />The PCCC object (code: hex 0x67) is not part of the ODVA spec - it is a vendor specific object used by Rockwell/Allen-Bradley to talk to SLC5, PLC5E and MicroLogix PLC. I won't fully explain it here ... not much to explain; do a wireshark trace of a ControlLogix talking to a SLC5/05 or MicroLogix 1100 and you'll see all you need to see about the simple object.<br /><br />The default service code of 0x4B has this form:<br /><span style="font-family:courier new;"><table border="2"><tbody><tr><td>Exec PCCC Service</td><td>4B</td></tr><tr><td>IOI to PCCC Object</td><td>02 20 67 24 01</td></tr><tr><td>Originator Info</td><td>07 03 85 50 4d 41 41</td></tr><tr><td>Example PCCC Message</td><td>0f 00 5c 00 a2 14 07 89 00 00</td></tr></tbody></table></span><br />The only mystery here should be the "Originator Info". The 07 means a total of 7 bytes (including the 07). 0385 is a unique sequence number which you should change between messages. The 504d4141 is a "CIP Serial Number" which must be unique to your vendor id - most vendors just use the last 4 octets of an Ethernet MAC address.<br /><br /><span style="font-style: italic; font-weight: bold;">However, there is NO remote node or slave address info</span>, so the Digi One IAP or 1761-NET-ENI will create a DF1 message for destination=1 and source=0. So back to the customer's question ... how to force a DF1 message with say destination=5 and source=2?<br /><br />The easiest solution is to switch to service code 0x4C, which has this form:<br /><span style="font-family:courier new;"><table border="2"><tbody><tr><td>DH+Like Service</td><td>4C</td></tr><tr><td>IOI to PCCC Object</td><td>02 20 67 24 01</td></tr><tr><td>DH+ Like Header</td><td>00 00 02 00 00 00 05 00</td></tr><tr><td>Example PCCC Message</td><td>0f 00 5c 00 a2 14 07 89 00 00</td></tr></tbody></table></span><br />So the "Originator Info" has been swapped with an 8 byte structure of the form AA AA BB XX CC CC DD XX. The "XX" are control bytes of some sort - just leave 0x00. "AA AA" is the Destination Link; "BB" is the Destination node; "CC CC" is the Source Link; "DD" is the Source node.<br /><br />Voila - both the Digi One IAP and the Rockwell 1761-NET-ENI will now create a DF1 message with destination=5 and source=2. Not too painful, was it.<br /><br />To my knowledge all Rockwell Ethernet/IP PLC accept either code, and if you'd like to see the service 0x4C in action just set your RSLogix5000 MSG block to use "CIP with Source ID" and the ControlLogix switches from using service 0x4B to using 0x4C.<br /><br />For completeness, there is a final service code of 0x4D with this form:<br /><span style="font-family:courier new;"><table border="2"><tbody><tr><td>Local PCCC Service</td><td>4D</td></tr><tr><td>IOI to PCCC Object</td><td>02 20 67 24 01</td></tr><tr><td>Example PCCC Message</td><td>0f 00 5c 00 a2 14 07 89 00 00</td></tr></tbody></table></span><br />It is documented in DeviceNet gateway manuals to reduce total byte count - but it also lacks any destination or source info so is of limited use in Ethernet-based systems.Lynn August Linsehttp://www.blogger.com/profile/01534730541144544922noreply@blogger.com2tag:blogger.com,1999:blog-35259639.post-52783227951417617092008-08-07T09:05:00.000-05:002008-08-07T10:23:13.512-05:00Creeping Firewalls and ChangeSummary: Network infrastructure changes can create unexpected havoc (surprised?)<br /><br />We had a customer come in with a complaint recently about some old products - a 4-port terminal server (a TS4) running <span class="blsp-spelling-error" id="SPELLING_ERROR_0">Modbus</span> bridging firmware. Things had gone on smoothly for years, but suddenly they started having problems which power-cycling the units solved ... obviously it's a <span class="blsp-spelling-error" id="SPELLING_ERROR_1">Digi</span> problem, right?<br /><br />Well, I'm not going to run through all of the issues, but I'll highlight one which will affect more and more people over time. Remember the old days - first you had dumb <span class="blsp-spelling-error" id="SPELLING_ERROR_2">dialup</span> modems, then you had to pay a lot for various error-detection standards, and now all analog modems have a big chip which does a hundred different standard things and you <span style="font-weight: bold; font-style: italic;">CANNOT buy any low-cost analog dial-up modem which is any dumber than state-of-the-art.</span> <br /><br />Such creep occurs in Ethernet switches also - once hubs were cheap and switches cost a king's ransom. Now even the "cheap" $19 home switches purchased in big-box stores are auto-sense, auto-cross, auto-<span class="blsp-spelling-corrected" id="SPELLING_ERROR_3">everything</span>. The same things happens - once the features are rolled into software or firmware, future revs of the product inherit such features for free ... said another way, it is often cheaper to sell lots of one powerful model than handle the marketing and support costs of a dozen models of various power and feature-set.<br /><br />Well, <span style="font-weight: bold; font-style: italic;">this customer had been upgrading their wide-area-network infrastructure</span> - a tangle of routed <span class="blsp-spelling-error" id="SPELLING_ERROR_4">IP</span>-based leased lines, old analog lines, radio/microwave links and so one, and as part of the improvement the various router/PPP end-points had added <span class="blsp-spelling-error" id="SPELLING_ERROR_5">stateful</span> awareness of packets ... part of an increase in US government security demands for utilities. After all, when you have hundreds of raw Ethernet ports scattered across rural American protected with little more than a padlock and chain-link fence, one has to consider the possibility of someone trying to 'jack' back into the 100% private network from a remote location.<br /><br />The issue with such an addition is that routers with firewalls commonly default to a 5-minute <span class="blsp-spelling-error" id="SPELLING_ERROR_6">TCP</span> life rule. Every <span class="blsp-spelling-error" id="SPELLING_ERROR_7">stateful</span> firewall creates a table entry for every <span class="blsp-spelling-error" id="SPELLING_ERROR_8">TCP</span> or <span class="blsp-spelling-error" id="SPELLING_ERROR_9">UDP</span> activity going "out" from a safer network and into a wilder, less safe network - your home <span class="blsp-spelling-error" id="SPELLING_ERROR_10">DSL</span>/Cable router does the same thing. NAT (etc) is optional, but bottom line is the firewall needs to understand and agree to the context of every packet trying to pass through.<br /><br />For a <span class="blsp-spelling-error" id="SPELLING_ERROR_11">TCP</span> socket this usually means at least 1 packet (data or <span class="blsp-spelling-error" id="SPELLING_ERROR_12">ACK</span> or <span class="blsp-spelling-error" id="SPELLING_ERROR_13">Keepalive</span>) must move every 5 minutes to refresh the context and inform the firewall that the <span class="blsp-spelling-error" id="SPELLING_ERROR_14">TCP</span> socket is still authorized. If no packets are seen, the fire wall discards the context and the socket is now ignored and 100% blocked without comment. Of course both <span class="blsp-spelling-error" id="SPELLING_ERROR_15">TCP</span> peers might think the socket is alive and well, but they will never be able to use it again.<br /><br />So back to our TS4 off in some remote field - a host computer has 4 <span class="blsp-spelling-error" id="SPELLING_ERROR_16">TCP</span> sockets open to it through various routed <span class="blsp-spelling-error" id="SPELLING_ERROR_17">subnets</span> and for whatever reason the host doesn't send any new packets for 6 minutes. The TS4 has no reason to talk since it is connected to <span class="blsp-spelling-error" id="SPELLING_ERROR_18">Modbus</span> slaves. So 6 minutes later the host issues 4 <span class="blsp-spelling-error" id="SPELLING_ERROR_19">Modbus</span> requests on 4 sockets, which hit the <span class="blsp-spelling-error" id="SPELLING_ERROR_20">stateful</span> firewall. The firewall looks up the context (called forwarding or trigger rules in some systems) and discovers there is no existing context for these <span class="blsp-spelling-error" id="SPELLING_ERROR_21">TCP</span> packets. Well, once upon a time the firewall would just assume since these were safe since they came from the safe side, and thus auto-create a new context, yet modern <span class="blsp-spelling-error" id="SPELLING_ERROR_22">stateful</span> firewalls might NOT do this since it was a common hacker exploit to fool firmwalls to move malformed packets. Thus modern security demands that the first packet of any new <span class="blsp-spelling-error" id="SPELLING_ERROR_23">TCP</span> socket be a [SYN] packet. All four packets are silently discarded as unknown (<span style="font-style: italic;">note: this is a configurable behavior in most firewalls - to auto-recreate a context for an 'old' <span class="blsp-spelling-error" id="SPELLING_ERROR_24">TCP</span> socket continuing or to only allow this for new <span class="blsp-spelling-error" id="SPELLING_ERROR_25">TCP</span> sockets.</span>)<br /><br />The TS4 never sees the four new request; the host sees neither an [<span class="blsp-spelling-error" id="SPELLING_ERROR_26">ACK</span>] nor a [<span class="blsp-spelling-error" id="SPELLING_ERROR_27">RST</span>] of the <span class="blsp-spelling-error" id="SPELLING_ERROR_28">TCP</span> socket, so it retries after 3 seconds, then 6 and so on. Eventually it comprehends the <span class="blsp-spelling-error" id="SPELLING_ERROR_29">TCP</span> socket has died and opens four new <span class="blsp-spelling-error" id="SPELLING_ERROR_30">TCP</span> sockets. These are allowed through the firewall since they contain the correct TCP state as being new sockets. The TS4 sees the four new socket requests and now has eight (8) sockets connected.<br /><br />Now you might say "What a minute - the four old sockets were closed!". Well, yes - the HOST knows they are dead and closed them, but the TS4 does not know this. Six minutes later, the same is repeated and the TS4 now has 12, then 16, then 20 sockets open. Eventually the TS4 runs out of resources, and the customer's open recovery option is a hard reboot of the TS4. This is of course worse if the host only <span class="blsp-spelling-corrected" id="SPELLING_ERROR_31">occasionally</span> takes longer than 5 minutes to poll, since the increase in TS4 sockets could take an unpredictable amount of time to build up.<br /><br /><span style="font-size:180%;">How to solve this problem?<br /></span><br /><ol><li>The first line of defense in the modern <span class="blsp-spelling-error" id="SPELLING_ERROR_32">IP</span> age is to always, ALWAYS enable <span class="blsp-spelling-error" id="SPELLING_ERROR_33">TCP</span> <span class="blsp-spelling-error" id="SPELLING_ERROR_34">keepalives</span> with an aggressive 4 minute 30 second idle time in any product you install. Even if you don't have <span class="blsp-spelling-error" id="SPELLING_ERROR_35">stateful</span> packet inspection within your <span class="blsp-spelling-error" id="SPELLING_ERROR_36">IP</span> network today, that doesn't mean the next time someone replaces a router or serial <span class="blsp-spelling-error" id="SPELLING_ERROR_37">PPP</span> end-point you won't gain one. Unfortunately the <span class="blsp-spelling-error" id="SPELLING_ERROR_38">Digi</span> products usually default to a 2 hour <span class="blsp-spelling-error" id="SPELLING_ERROR_39">TCP</span> <span class="blsp-spelling-error" id="SPELLING_ERROR_40">Keepalive</span> - which is also disabled (for historical reasons). Yet having a 4.5 minute keepalive would have saved the TS4 because the first time the host delayed longer than 4.5 minutes to poll, the TS4 would have sent a <span class="blsp-spelling-error" id="SPELLING_ERROR_41">TCP</span> <span class="blsp-spelling-error" id="SPELLING_ERROR_42">keepalive</span> packet back through the <span class="blsp-spelling-error" id="SPELLING_ERROR_43">stateful</span> firewall, which the host returns and the <span class="blsp-spelling-error" id="SPELLING_ERROR_44">firewall's</span> context for this socket is refreshed. Thus when the host does finally send the next <span class="blsp-spelling-error" id="SPELLING_ERROR_45">Modbus</span> poll after 6 minutes (1.5 minutes after the <span class="blsp-spelling-error" id="SPELLING_ERROR_46">TCP</span> <span class="blsp-spelling-error" id="SPELLING_ERROR_47">keepalive</span> exchange) the firewall is <span class="blsp-spelling-corrected" id="SPELLING_ERROR_48">satisfied</span> with the packets and forwards them out to the TS4. Everyone is happy. Plus even if the <span class="blsp-spelling-error" id="SPELLING_ERROR_49">TCP</span> socket has been aborted by the firewall, the TS4's <span class="blsp-spelling-error" id="SPELLING_ERROR_50">TCP</span> <span class="blsp-spelling-error" id="SPELLING_ERROR_51">keepalive</span> will be <span class="blsp-spelling-error" id="SPELLING_ERROR_52">silently</span> discarded and the TS4 will retry and <span class="blsp-spelling-corrected" id="SPELLING_ERROR_53">eventually</span> comprehend that the <span class="blsp-spelling-error" id="SPELLING_ERROR_54">TCP</span> socket is no longer valid. This is the purpose of TCP Keepalive - to allow a TCP peer with no data to move to test (and refresh) the health of an idle connection.<br /></li><li>The second possibility is unique to the <span class="blsp-spelling-error" id="SPELLING_ERROR_55">Digi</span> IA/<span class="blsp-spelling-error" id="SPELLING_ERROR_56">Modbus</span> application. You can enable a setting <span class="blsp-spelling-corrected" id="SPELLING_ERROR_57">referred</span> to as "<span class="blsp-spelling-error" id="SPELLING_ERROR_58">idletimeout</span>" on incoming client or outgoing server connections. Unlike the <span class="blsp-spelling-error" id="SPELLING_ERROR_59">TCP</span> <span class="blsp-spelling-error" id="SPELLING_ERROR_60">Keepalive</span> which create traffic and keeps an idle socket open, the <span class="blsp-spelling-error" id="SPELLING_ERROR_61">idletimeout</span> literally just aborts an idle socket without giving it any chance to prove it is healthy. So setting a 5 minute idle timeout in the TS4 would cause it to just assume any incoming <span class="blsp-spelling-error" id="SPELLING_ERROR_62">Modbus</span> client (master) connection which has NOT sent a new request is bad. This setting would also have saved the TS4, forcing the four old sockets to be aborted before the TS4 had a chance to build up a herd of dead sockets.</li></ol>So understanding TCP Keepalive is a critical skill for all modern industrial Ethernet users, after all more and more facilities are breaking their floors and functional area into distinct subnets with stateful firewall protection to keep the Accountants from changing the color of the widgets being produced - and to keep the production engineers from printing on the accounting departments laser printer which uses red ink :-).<br /><br /><a href="http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html">More complete discussion of TCP Keepalive is here</a> (one of dozens of web site you can find in a web search).Lynn August Linsehttp://www.blogger.com/profile/01534730541144544922noreply@blogger.com0tag:blogger.com,1999:blog-35259639.post-6957170313088172332008-08-01T11:51:00.000-05:002008-08-01T12:06:21.254-05:00Tunneling Serial Data over Cellular<span style="font-size:130%;">Tunneling Serial Data over Cellular</span><br /><br /><span style="font-weight: bold;">Question</span>: you have a Windows-based application which expects to talk over normal serial ports - how can you connect to a remote serial device over a cellular-IP link?<br /><br /><span style="font-weight: bold;">Products</span>: works with Digi Connect WAN, WANIA or WANVPN, Digi ConnectPort VPN, X4 or X8<br /><br /><span style="font-weight: bold;">Answer</span>: Our Digi RealPort driver for Windows 2000/XP/Vista dated Nov 2008 now supports a nice low-overhead "UDP: Serial Data Only" mode. This will cost a fraction of what normal TCP-mode Realport or competitors TCP redirectors will cost.<br /><br />Here is a web page explaining how to install RealPort for UDP mode (DDNS names can be used!)<br /><a href="http://digitips.wikispaces.com/Digi+Realport+with+UDP">http://digitips.wikispaces.com/Digi+Realport+with+UDP</a><br /><br />Here is a web page explaining how to set the WANIA to UDP Sockets.<br /><a href="http://digitips.wikispaces.com/Digi+UDP+Sockets+WAN">http://digitips.wikispaces.com/Digi+UDP+Sockets+WAN</a><br /><br />I set this up yesterday and have been polling a Modbus/ASCII serial slave on my CPX4 using RealPort and UDP mode. Responses take from 2 to 3 seconds to return … in part because I am polling so slowly that the modem PARKS in between every poll and I wait 30 seconds for a response timeout. I see perhaps 0.25% error / no response timeout but then my SIM doesn’t have the best signal where my product sits.<br /><br />However, I still believe people need to be realistic – even in the situations where the slave response times out I’d suggest NOT retrying immediately since the retries have a higher than normal probability of failing as well. Missing a few polls a day is better than needlessly paying more for data plans.Lynn August Linsehttp://www.blogger.com/profile/01534730541144544922noreply@blogger.com0tag:blogger.com,1999:blog-35259639.post-87154867216156994002008-07-23T14:28:00.000-05:002008-07-23T15:29:46.692-05:00Evolution of Data Plan Billing<span style="font-weight: bold;font-size:130%;" >Summary: the big three have moved away from unlimited data, towards limited data.</span><br /><br />It is interesting - I once (as in last year) had a talk with a potential partner who'd been at some European conference and was convinced the world was on the verge of low-cost (sub-$20/month) unlimited cellular data plans. We were discussing the creation of report-by-exception tools to reduce SCADA costs, and this partner's strong faith in this belief caused them to eventually bail out of the talks, saying "<span style="font-style: italic;">In a year or two, no SCADA company will care about how much cellular data they use</span>."<br /><br />Yet as of the summer of 2008 the world of cellular data is moving in the opposite direction. Last year the big three (AT&T/Sprint/Verizon) offered "Unlimited Data" for personal users with the Service Terms listing a VERY narrow list of permitted activities - mainly email and web browsing, with many common things like file download/upload, media-streaming prohibited. So when ever one of the big three would <span style="font-weight: bold; font-style: italic;">cut off a user for moving too much data on an "unlimited plan"</span>, the service provider would fall back on the "<span style="font-style: italic;">You are doing prohibitted things, thus impacting our network, thus take your business elsewhere</span>". What a way to cause bad feelings, eh? <span style="font-style: italic;">Note that this change is CONSUMER plans - machine-to-machine have always been limited, priced by the MB/month without rollover, plus with charges for data overages.</span><br /><br />Now all three have dropped the price from the $80/month range down to $60/month range ... but added a hard limit of 5GB per month. Isn't free & vigorous market competition wonderful?<br /><br />Sounds reasonable - 5,000 megabytes of data is a lot, yet this doesn't mean 5GB of data transfer. It means 5GB of metered activity, with many activities I've studied including up to 95% overhead. Thus someone only moving 20-30MB of real data in small packets per month might hit pretty close to their 5GB limit! My experience with normal wide-area-network traffic hints that a real PC user doing simple email and web-browsing once a day would probably move 1-2GB of data before hitting the 5GB total activity limit.<br /><br />To paraphrase the wireless data service terms for all three:<br /><ul><li>Data transport is always measured in full kilobytes</li><li>Actual transport is always rounded up to next full-kilobyte at "end of session"</li><li>Network overhead and resend requests caused by network errors can increase measured kilobytes.</li><li>2 of 3 mention always rounding up to nearest kilobyte every hour period.</li><li>All warn that you will NOT receive an itemized detail of how your charges are calculated; you will NOT see which services were used or during which time periods the charges were inccurred under.<br /></li></ul>So if I send a single 50 byte UDP/IP packet, is that a full session and billed as 1024 bytes? Could be under this language since UDP is 'sessionless'.<br /><br />Hmm, the term <span style="font-weight: bold; font-style: italic;">session </span>is pretty ambiguous. Perhaps it means per "time you enable your PC-based cellular data card." That seems likely - plus if you left your device on twenty-four hours a day then the once per hour round-up would catch you.<br /><br />I'm afraid I haven't offered any new answer here, other than to suggest you understand that <span style="font-weight: bold; font-style: italic;">low-cost unlimited data plans ARE NOT just around the corner</span> ... at best we left them behind last year and I don't foresee them ever returning. I suppose all three now understand that huge new profits are to be made with these 5GB limits, which will cause many "super-salesman" using their cellular data plan daily to spend an extra $50 to $500 in monthly overage charges.Lynn August Linsehttp://www.blogger.com/profile/01534730541144544922noreply@blogger.com0tag:blogger.com,1999:blog-35259639.post-72415156637791414872008-07-11T11:56:00.000-05:002008-07-11T12:13:13.801-05:00Lower Cost Cellular to Rockwell AB PLC<p>I have several customers now working through how to manage cost-effective cellular access to Rockwell PLC such as ControlLogix, CompactLogix, Micrologix 1100 and so on. Unfortunately the most straight forward way to link using Ethernet/IP is fairly costly.<br /></p>First, a personal recommendation from me – a free tool which I find very useful and think you will too. Today, you can buy 2GB USB flash drives for $15 – if you're old like me, you remember when an entire Windows computer only had 0.020GB of hard drive space! <span style="font-weight: bold; font-style: italic;">Did you know you can literally install and run many Windows applications from these portable USB drives? </span>This means any Windows computer you plug this USB drive into has your applications, your settings, and your data files. I've used one of these for over a year and it is invaluable - all free open source code too! You can run <a href="http://portableapps.com/apps/office/openoffice_portable">OpenOffice</a> (which can read/write MSOffice 2003 files and is much faster than the MSOffice 2007 we use at Digi), <a href="http://portableapps.com/apps/internet/firefox_portable">Firefox web browser</a>, plus a dozen other tools. <a href="http://portableapps.com/apps/utilities/keepass_portable"> Take a special look at KeePass</a>, which I use daily from my USB drive to securely hold all of my hundred-plus account names and passwords.<br /><p style="margin-bottom: 0in;"><a href="http://portableapps.com/about/what_is_a_portable_app">Portableapps.com - What is a Portable App?</a><br /></p><br /><p>Okay, back to work.</p><br /><p><span style="font-size:180%;">Periodic PLC Access from RSLogix</span></p>Customers who want to peek into a single PLC at a remote site for an hour or two can use RSLinx to connect to either an IP or DNS name, then see the PLC via cellular. The catch is RSLinx will create from 12MB to 200MB of background traffic per month. So you need to create a new Ethernet Driver (not Ethernet/IP!) JUST for this one-time use, configure in your details, connect and do your work. When you are done you need to turn browsing off, then delete the comm driver. Why not just delete the IP or DNS name? Unfortunately once RSLinx has seen a device, it can be like a bad rash to get rid of it.<br /><p><span style="font-size:130%;">Data polling – at Central Office</span></p>Customers with an OPC server speaking DF1, CSPv4, or even Ethernet/IP can poll PCCC-type data through a <a href="http://www.digi.com/products/serialservers/digioneiaphaz.jsp">Digi One IAP</a>, which converts the polls into <a href="http://iatips.com/rockwell.html#common">DF1 Radio Modem</a> under UDP. Tests have show using DF1 Radio Modem every few minutes accomplishes the same data movement as Ethernet/IP with only 5% the data cost (or Ethernet/IP uses 2000% more data bytes). One unit of Digi One IAP can poll up to 60 remote IP or DNS names. If your OPC server can encapsulate DF1 Radio Modem directly into UDP/IP, then you won't need the Digi One IAP to act as your host.<br /><p><span style="font-size:180%;">Data Polling – at Remote Site</span></p>If you have an <span style="font-weight: bold; font-style: italic;">AB PLC which speaks DF1 Radio Modem</span> directly, then any Digi cellular router can be configured for UDP Sockets, with shuttles UDP data received to the serial port. Make sure you use the latest Digi firmware so it can just return UDP responses to last sender without explicit address configuration.<br /><p>If your <span style="font-weight: bold; font-style: italic;">AB PLC doesn't speak DF1 Radio Modem</span>, or you want to use an Ethernet link, then using a Digi cellular router with Python support allows a simple script which accepts DF1 requests and uses a local Ethernet/IP session to query responses from the PLC's PCCC Object. This Python code even runs on a PC under Windows or Linux. As soon as I have a link or web page explaining how to get and use this code, I'll edit this post to add it here.<br /></p><br /><br /><p></p>Lynn August Linsehttp://www.blogger.com/profile/01534730541144544922noreply@blogger.com0tag:blogger.com,1999:blog-35259639.post-48674092616141149432008-07-10T16:54:00.000-05:002008-07-10T17:05:06.917-05:00Quick Data Comms to AB PLCOne of my readers was asking for a quick way to talk via Ethernet to a Rockwell AB PLC.<br /><br />You can actually talk to a ControlLogix by only understanding TWO (2) different packets, each with a response, so four packets I guess. The problem is this uses "UCMM" style communications, which the PLC has very limited resources for. Said another way, the CIP Connected Messaging or I/O production both include an inherent allocation of resources, while the UCMM is designed to be used ONLY to setup such pre-allocated resources.<br /><br />So yes, you can use the information below to create a literal quick-n-dirty solution, and if you talk more than a few times a second you might start to interfer with other communications to the PLC (which is not a good thing!) However you could treat this as a proof of concept, and then work to do the communications more fully per the ODVA specs.<br /><br />Here is the PDF of <a href="http://iatips.com/digiwiki/quick_eip_demo.pdf">how to read/write to the PCCC Object in a Logix Processor</a> here.Lynn August Linsehttp://www.blogger.com/profile/01534730541144544922noreply@blogger.com1tag:blogger.com,1999:blog-35259639.post-86955162269116187072008-05-30T09:06:00.001-05:002008-05-30T09:42:33.059-05:00Public Internet Risk in Common ToolsTwo months ago a SCADA customer asked me to enable FTP (File-Transfer-Protocol) on a test RTU they'd sent me to put online for them. It was on a DSL link and although I warned them it was a bad idea they said it would be okay because the RTU had username/password protection and the RTU had nothing important on it.<br /><br />The punchline is that a few days later the customer sent me an email saying they couldn't FTP into the RTU anymore, so couldn't check the log files.<br /><br />I looked, and the RTU now had 3 TCP sockets open (all the sockets allocated for FTP on this RTU) to some FTP client at an IP address registered in Korea. All 3 were just slowly walking through a dictionary attack of username/passwords (user <span style="font-weight: bold;">bill</span>, pass <span style="font-weight: bold;">honda14 </span>... user <span style="font-weight: bold;">billk</span>, pass <span style="font-weight: bold;">12tomes </span>...) No doubt the IP and FTP client belonged to some university student running kiddy-scripts obtained on the Internet. No doubt the kid probably didn't even care if the odd device he or she had never seen before was not a computer (<span style="font-style: italic;">FTP servers always announce what and who they are when you connect</span>). No doubt this attack wasn't costing them anything, as either the university or parents were paying for the Internet connection - or the IP and connection belonged to some patsy whose home computer had been compromised.<br /><br />So okay, it was not causing any real harm, <span style="font-weight: bold; font-style: italic;">except it defeated the purpose of enabling FTP since the end user no longer had access to FTP.</span> I suppose you could call it a denial-of-service attack, yet I'm sure that was NOT the intension of the '<span style="font-style: italic;">attacker</span>'. The student was probably just hoping to be able to post a message on some forum saying '<span style="font-style: italic;">I hacked a computer at this IP address in the USA, and here is the FTP user name and password I created for you to access.</span>' The fact that the RTU only contained a dozen binary log files would be irrelevant.<br /><br />Do I have a moral to this story? Hmm, not really - other than industrial users have to understand that what is NOT interesting to them might be interesting to others for very different reasons.<br /><br />If this user had allowed me to change the FTP port to some random value like TCP port 38207, then it is very likely this particular student would NOT have found it. Since true port-scans are so easy to detect, the student's tool probably had a list of a few dozen TCP ports commonly used by FTP servers, then it would randomly try them over a few weeks at any single target IP.<br /><br />The same story could be true for web servers on TCP port 80 (or 8000 or 8080). Digi ships our cellular products with the web server enabled on port 80 because that is what customers expect. Sure, they add a username and password, but what will happen to their data plan bill if their 3MB per month plan moves 3-GigaByte because some scripts are trying dictionary attacks on the login of home web page?<br /><br />I've had to always mention that 3GB part (meaning a $500+ bill for a month) since every time I mention to such users not to leave port 80 setup as a web browser, the industrial customer's answer is invariably '<span style="font-style: italic;">... it'll be okay because the unit has username/password protection and it has nothing worth trying to see on it ... </span>'Lynn August Linsehttp://www.blogger.com/profile/01534730541144544922noreply@blogger.com0tag:blogger.com,1999:blog-35259639.post-45010525692024976752008-05-22T11:34:00.000-05:002008-05-22T12:05:04.704-05:00Cellular to Wireless ZigbeeAn interesting new market we are moving into is cellular access to wireless mesh (Zigbee as example). In some sense it's a supply-chain dream come true. Imagine you supply a product to customers and EVERYONE (except the customer's IT department) want you to be able to see what the stock level is and auto-schedule deliveries.<br /><br />The customer benefits because they can treat the product as a 'utility' - turn the tap and there it is.<br /><br />You benefit because you can minimize emergency truck-rolls - no more angry, panicked customers demanding you send a truck over two-thirds empty because someone forgot to schedule a special delivery because the customer needed to use 60% more product for two days. Of course as a supplier the cost of the truck, fuel, and driver are critical parts of your margin/profit. You desire to only send out full trucks which return gracefully empty!<br /><br />So we are now working with several of the largest chemical suppliers in the world to enable:<br /><ol><li>drop in a powered cellular unit at the customer site</li><li>drop in powered or battery tank sensors</li><li>log levels hourly, for the supplier to upload daily (reduces cellular data charges) The supplier uses this as their 'secret-sauce', their own proprietary value-add to predict when trucks need to roll to maximize efficiency<br /></li><li>enable alarm call-out if the levels hit unexpected low-low levels<br /></li></ol>How this works varies by suppliers. The one I'm working with is using Modbus/TCP to pull up the logs daily. Some other suppliers are having SMTP clients push emails back to the supplier with XML formatted reports. The next supplier I might work will wants the binary logs to be compressed (ZIP'd) and then pushed upstream once a day by FTP, where their accounting system will convert from binary to XML to import and issue bills on product usage per MINUTE.<br /><br />Of course key to all of this is the <a href="http://www.digi.com/products/wirelessdropinnetworking/">wireless drop-in-network concept</a>. The supplier doesn't want to invest thousands of dollars pulling wires through SOMEONE ELSE'S PLANT - especially when the supplier's contract might end in a few months. <br /><br />Wireless sensors aren't new; cellular data access isn't new; supply-chain systems which auto-detect product levels aren't new. What is new here is the merger of many technologies which reduce infra-structure costs, and thus increase ROI.Lynn August Linsehttp://www.blogger.com/profile/01534730541144544922noreply@blogger.com3tag:blogger.com,1999:blog-35259639.post-61497943606262824472008-03-14T09:42:00.000-05:002008-03-15T11:40:33.293-05:00PCCC Protected Typed Logical Write with MaskSomeone asked about the "<span style="font-style: italic;">DF1 Supplement for SLC500</span>" from 1995 which was online at ab.com for a short period, then was pulled - probably because it is a very poor quality optical scan. However, I had it ... then lost it ... then found it stashed away on one of my ftp sites. <br /><br />So here is the original AB PDF (which I downloaded from ab.com last year) <a href="http://iatips.com/docs/DF1%20Protocol%2017706516%20Suppliment.pdf">Grab it here while it survives</a>.<br /><br />The masked write is on page 11 and the first data-word is the mask and all data following has the SAME mask applied. So [0x0001,0x0000] would clear the LSBit and so on. It doesn't offer mask-data pairs - just one mask and N words. Thus this command is mainly for use with 1 word element writes ... unless you have three or four consecutive N-file words you wish having the same mask applied.Lynn August Linsehttp://www.blogger.com/profile/01534730541144544922noreply@blogger.com0