Finding the distance between two GPS Coordinates ML1400

[Tlogix 1]

Hi Guys, I have a Garmin 18xLVC GPS Puck connected to a ML1400. I'm reading the GPGGA String and parsing the Latitude and Longitude to get a number like (48.92746, -97.24758) I have a Static Location in the PLC in the same format IE (48.23622, -97.23556) I need to find the distance between the Static location and the Location coming in from the GPS puck. I'm doing the calculation like in the attached program, but it looks like it's messing up on the ACOS function because the previous step is getting a .999999991092633 and the controller is rounding that to a 1. I think we're trying to do something that this controller isn't capable of doing, Please tell me I'm wrong!! All we need to do is find distance between two GPS locations, doesn't sound all that complicated, but maybe it's outside the scope of what the ML1400 is capable of doing. thanks in advance for any help. GPS Math For Form.RSS

[TimWilborne 108]

This is a good challenge and should be possible with some creative math, but I've got to get the final drawings done for a project before I can play. I was wondering what I would work on when the snow comes. If no one comes up with a solution before tomorrow I'll give it a shot.

[JRoss 84]

You're running into the limitations of floating point in a PLC. You're looking for an awful lot of significant digits, more than I think the processor is capable of representing. The number is stored in a 32-bit data type as a form of scientiific notation with a 24-bit mantissa, which only can handle about 7 significant digits. Plus, PLC's use a binary implementation of floating point that isn't as precise as the decimal implementation. Wikipedia has a nice article on the subject. See especially the section on accuracy problems. Unless somebody else can think of a creative solution I think you're out of luck with the Micrologix. You could look into a PLC with double-precision (64-bit) floating point, but they're going to be the high-end ($$$) models. You might be better off investigation an embedded processor.

[phuz 2]

JRoss is right. You have hit the wall of the MLx. Do you have an HMI attached to this?

[Tlogix 1]

We do have a HMI Attached, but we can't use it to do the calculations because of how we handle polling to the PLC's. We have anywhere from 10 to hundreds of these PLC's connected to one HMI Server, and we poll one PLC every three seconds, or upon request from the user. If we have 10 PLC's on one HMI Server, it would take roughly 30 Seconds to make a round to all the PLC's, providing there are no communication losses. However we need the calculation to be run more often than that, about once every two or three seconds. Edited 13 Feb 2014 by Tlogix

[phuz 2]

Well that's tough. I obviously don't know your process or network limitations, but why not up the polling rate?

[Tlogix 1]

We're on a 900Mhz wireless network, hence the long polling interval, plus the polling stops when a user logs into one of the PLC's. I wish we could do it with the HMI, that would solve alot of problem's we've had with this system.

[JRoss 84]

You're going to need to out-source the math one way or another. I'd investigate micro-controllers, which are more difficult to configure but are relatively cheap for the hardware. Just make sure it can handle double-precision floating point and two serial ports (one for the puck and one to transmit the final number to the PLC). I don't have any experience, but a Google search pulls up some possibilities: Arduino Raspberry Pi SPLat PIC

[Ken Roach 194]

How accurate do you need to be, and how far are the distances you are measuring ? If those coordinates you gave are an example, you're looking at measuring a handful of kilometers out in the prairies. For those distances, you can just use a Pythagorean approximation and get "pretty good" results. An online calculator that uses 64-bit math gave me 850.3 meters for those coordinates, and my math in an SLC-5/05 gave me 849.97, so a difference of less than half a meter. Edited 14 Feb 2014 by Ken Roach

[Ken Roach 194]

Here's a relay ladder example written for the SLC-5/05 controller on my desk, using only the standard Math and Trig functions that the MicroLogix 1400 should also support. I think the A-B Micro 800 supports 64-bit math to some extent, since I know I've seen an example of solar array tracking using high-precision math. I have a Micro 830 in the shop but not a lot of time to fiddle with it. Not really the point, since you say you've got MicroLogix 1400 controllers already installed. Pythag_Approx.RSS Edited 14 Feb 2014 by Ken Roach

[Tlogix 1]

We need to be as accurate as the GPS puck can deliver, three meters or so. We need to measure anywhere from 0 to 5280 feet. I'll check out your program now. thanks for all the help guys! I'll be sure to post my solution, if I find one.

[Tlogix 1]

Hi Guys, So I did some tests with Ken's Logic in a ML1400, and a compared it to an Arduino Uno with the TinyGPS++ Library. Turns out Ken's logic is as accurate as the Arduino, which is as accurate as the Garmin 18xLVC can deliver. So thanks a million Ken!!! if anyone want's the code I used in the Arduino, I'll gladly share it. I used an iPad with mySCADA as the HMI for the PLC and a SainSmart LCD for the arduino. Edited 14 Feb 2014 by Tlogix

[JRoss 84]

Just now looking at Ken's code. Definitely something to add to my bag of tricks!

[Michael Lloyd 85]

I came to the party too late to help but soon enough to see Ken'c code :) I was going to suggest using an Arduino or even a Tinyduino from here https://tiny-circuits.com/ but I guess that wouldn't be viable because the GPS uses up the serial port connection on the ML And since it seems that a lot of us have an interest in programming that is outside of the realm of the PLC- Check this little quad copter out- http://www.makershed.com/Crazyflie_Nano_Quadcopter_Kit_10_DOF_p/mkseeed14.htm

[Tlogix 1]

If Ken's code didn't work, We would've had to put the Arduino in-Line on the GPS. So the GPS would connect to the Arduino via SoftwareSerial, then the Arduino would give the ML1400 a Serial String from the real Serial Port on the Arduino (pins 0 and 1). It would've worked, but it's just another piece of hardware that we don't want, or need, thanks to Ken.

[Michael Lloyd 85]

The libraries that are available for the Arduino seem to be endless. Because it's open source, the Arduino isn't really usable for commercial ventures, but the Atmega microprocessor is so that doesn't matter. Ken's solution is pretty elegant and portable... gotta like that

[Ken Roach 194]

I'm glad to see that the code worked in practice, and not just on my desk. Credit goes to Pythagoras, and these guys: http://www.movable-type.co.uk/scripts/latlong.html