Trying to communicate the BS2p40 to a hilti laser range finder.

jkon80

·RS-232 beginner.· I'm trying to communicate to a hilti laser range finder using its rs-232 port to the parallax RS232 DCE AppMod. My goal is to control the hilti·with the BS as if it were the computer.· I have the data strings available for the hilti but I'm having trouble comunicating with it.· The hilti device only uses TX RX and GRD.··PLease help!·

Chris Savage

You haven't provided any specifications, a datasheet or even a clue as to how the device communicates which could be used to assist you.· Please provide details of how this device works, what communications protocol it uses and what information is sent between the device and controller.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com

Bruce Bates

jkon80 -

Which of the various Hilt Laser Rangfinders are you using. I haven't found one yet, that appears to have an RS-232 port on it, and I've downloaded the manuals for 3-4 of their rangefinder products.

Regards,

Bruce Bates

Robert Kubichek

Bruce Bates said...
jkon80 -

Which of the various Hilt Laser Rangfinders are you using. I haven't found one yet, that appears to have an RS-232 port on it, and I've downloaded the manuals for 3-4 of their rangefinder products.

Regards,

Bruce Bates

Well, The PD28 has downloadable capabitlities....

Bob N9LVU

jkon80

This is most of the information I could find about the device. There is a excel based program used by the PC to control the Hilti. I'm trying to get the BS to mimic the PC program if possable.

The serial interface of the Hilti is available to be directly connected to a PC. The interface parameters are (9600 baud, even parity, 7 data bits, 1 stop bit)

The hilti output data contains various data words with 16 ASCII characters each. The first 8 characters consists of identifiers, attributes, Unit parameters and signs while the last 8 characters define the value (the value is all I need).

Typical output structure of data word from the hilti
Word Identifier (Wi), Extended attributes (w), Units (U), sign (+or-), Values (V), Delimiter (_)

Word character (Wi) (Wi) (w) (w) (w) (U) (+or-) (V) (V) (V) (V) (V) (V) (V) (V) (_)
Character position 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Data word example: 314.06+12849358 ... 1284.9358m

Remote operation standard set of comands
On command (a),(A)
Function: Switch on or reset
Input: a<cr>; A<cr>
Output: ?<cr><lf> or @Exxx<cr><lf>
Off command (b), (B)
Function: Switch off
Input: b<cr>; B<cr>
Output: ?<cr><lf> or @Exxx<cr><lf>
Laser Beam On/Off
Function: Switch laser on/off
Input: o<cr> Laser on
p<cr> Lasor off
Output: ?<cr><lf> or @Exxx<cr><lf>
Measure single distance
Function: Triggers single distance measurement with short output
Input: G<cr>
Output: Wl31<cr><lf> or @Exxx<cr><lf>
ect.

The input command is the information recieved by the hilti. Each command consists of one or more characters and a terminator. A command is concluded with an ASCII code carriage return <cr>. An additional line feed <lf> character is permitted but has no effect, <lf> is optional (for reasons of compatibility only).

jkon80

Hilti PD 28

Bruce Bates

jkon80 -

I see three potential problems at the moment, although there's still no harm in trying. There may even be more than just these. Here are the three potential problems I presently see:

The first potential problem is that the PD28 expects a proprietary piece of software at the other end. This is the (so called) "Hilti Server Software". Whether it will exchange or transmit information without that proprietary software at the other end, remains to be seen, and may be a problem.

The second potential problem, if you get by the first, is that the data being expressed will apparently be suitable for Microsoft Excel. I can only presume that will entail a lot of decimal, and non-integer numbers, and possibly floating point numbers as well. Even IF you can read them into a Stamp, I'm not sure that there is any way the Stamp could work with them, or process them as the appropriate "numbers" that they are intended to express.

The third potential problem I forsee, is that the data coming out can involve a farily large number of columns and rows; larger than the RAM of the Stamp may be able to handle in one "gulp". Presently we know of no way of saying "Hand me one record at a time" even, so this may end up being a continuous "blast" of data which is no big deal for a PC, but will swamp most microcontollers very easily without a suitable input buffer.

I hope these thoughts don't prove to be impediments, and that you're able to extract your data. In the end, however, downloading to a laptop may make a lot more sense.

Regards,

Bruce Bates

Paul Baker

the three issues you bring up Bruce can be worked around, but each makes the task all the more difficult. Work-arounds for each:

RS-232 sniffer: monitor the communications that take place to reverse engineer a solution so a stamp can interface with the unit.

BCD math: by using BCD mathmatics, numbers of arbitrary length can be accomodated. Normally restricted values A-F can be used to indicate decimal point, exponent, negative sign, end of number, etc.

Adding an external memory, filling up the memory with the burst of data to be later processed by the stamp.

All possible, but adds to the complexity of the project.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

jkon80

This is what I've gotten so far from playing with the communication of the Hilti PD28.

I first monitored what the PC was sending to the Hilti by placing the stamp in series with the communication link between the two. What I received from the debug of the stamp was consistent but not the ASCII characters I was expecting. I'm getting "x" and "y" among others depending on the command I send from the PC. Then I tried linking the Hilti to the Stamp. I tried sending the character "b" , "a" , "x" , "y" with the CR to attempt to turn the device on or off in reply to all of these I get a (DEC 127) Which I assume is an error. Maybe the device is looking for the software. I don't know I need to check with Hilti to find that info.

Thanks for your help
Jason

Bruce Bates

Jason -

I'm glad I haven't dissuaded you. You may want to take a run over to the WinTech Software web site, and pick up a copy of "Listen32" which is a software datascope which can trap all of the data passing through an RS-232 connection on a PC! It has a number of other capabilities too, as you will see in the documentation. here is a link to the demoware:
http://www.win-tech.com/html/demos.htm

Scan about 1/2 way down the page to find "Listen32".

Regards,

Bruce Bates

jkon80

Thanks Bruce, what you suggested about the serial port monitoring helped. I'm communicating to the PD 28 succesfully. I need a little insight as far as capturing the data needed. Right now I'm succesfully getting the bytes I want individually but I'm having trouble getting them all at once. I'm using [noparse][[/noparse]SKIP 11, DataIn] to get the 12th byte. If I use [noparse][[/noparse]SKIP 12, DataIn] I get the 13th byte that I should be getting. I tried [noparse][[/noparse]SKIP 12, STR DataIn\4] to get the whole string that's needed but the first character is correct while the following three are consistant but not the correct characters I was getting individually. What is the proper line of code to SERIN skipping the first 11 bytes and then capturing the the last 5 (5th being a delimiter)?

Bruce Bates

Jason -

It would be helpful if we could see the actual code you used, rather than a description of that code. My suspicion at the moment is that DataIn is not defined as an array.

Regards,

Bruce Bates

jkon80

I used DataIn just as a description. here is the code I'm using to test the communitcation.
The code is simple. I'm new to programing the BS. Maybe there is a better way to write the program.

(Using the BS2)

Hilti VAR Byte(5)

pin1:
SEROUT 1, 8276 [noparse][[/noparse]"G",CR] 'Single measure command.
DEBUG "G",CR
GOTO pin0

pin0:
SERIN 0, 8276, [noparse][[/noparse]SKIP 11, Hilti ] 'OR [noparse][[/noparse]SKIP 11, STR Hilti\4]
DEBUG "Pin3 of Hilti=", Hilti,CR 'OR STR Hilti\4,CR
PAUSE 500
GOTO pin1

Bruce Bates

Jason -

In lieu of using "[noparse][[/noparse]SKIP 11 STR\4]" you need to use "[noparse][[/noparse]SKIP 11 STR\5]" to SKIP 11 bytes, and fetch 5 bytes. Those five bytes can then be addressed individually as: Hilti(0), Hilti(1), Hilti(2), Hilti(3), and Hilti(4).

I have re-written your test program slightly, just so it's a bit more understandable, and added some comments:

Hilti VAR Byte(5) 'Data array to hold info from rangefinder

Send_Command:

SEROUT 1, 8276 [noparse][[/noparse]"G",CR] 'Single measure command.
DEBUG "Sent G",CR 'Show command on DEBUG terminal

Receive_Reply:

SERIN 0, 8276, [noparse][[/noparse]SKIP 11, Hilti\5 ] 'Field reply from rangefinder
DEBUG "Pin3 of Hilti=", Hilti\5,CR 'Show data on DEBUG terminal
PAUSE 500 'Wait a bit
GOTO Send_Command 'Go back and do it again
END

Regards,

Bruce Bates

jkon80

I guess the stamp and the Hilti didn't like using the SKIP command. I'm getting better results by pulling the entire string then grabbing the values needed using Hilti(11), Hilti(12), Hilti(13), Hilti(14), and Hilti(15), etc. Uses a lot of memory but I can work around that. I'm retrieving the data from the Hilti successfully. Thanks for all your help.

Jason