DT800 logger.

I want to communicate over the serial port with a Programmable Counter (ESTERS PMO2160), which reads pulses from a pair of proximity switches, sensing targets on a wheel (essentially a rotary encoder), and calculates a counter value for the number of revolutions, displays it and optionally transmits it on a RS-485 port.

All this works fine, and the values on the display/port are correct. To read the values into the DT800, I have to communicate with the counter.

It works according to a German industry standard (DIN66019), with a byte oriented protocol where a master sends data to slaves on a RS-485 bus.

A communication sequence would in brief look like like below. Since the logger is used for measurements, I don't want to disconnect it for too long to play around with it.

So being a little unfamiliar with the syntax of the DT800, I hope someone could look this over, an suggest changes, if needed (or encourage me to go and get the logger, and re-program it :-)

The details:
First a Master -> Slave telegram is sent, to poll the counter, which immediately responds with a similar telegram containing three BCD coded bytes, which constitute the display value.

The decoding of the BCD to a numeric value can be done later in the data flow, and is no issue here (suggestions welcome, though).

So, in byte-language:
Master->Slave: DLE-SOH-ADD-ADS-NOB-FCN-PAR-DLE-ETX-BCS
Slave->Master: DLE-STX-BCN-NOB-BY1-BY2-BY3-DLE-ETX-BCS Mnemonic binary decimal DLE(10h) 00010000 \016 SOH(01h) 00000001 \001 STX(02h) 00000010 \002 ETX(03h) 00000011 \003

BCS Binary Check Sum successive XOR of the bytes in the message, excluding start sequence DLE-SOH and end sequence DLE-ETX Mnemonic Explanation Actual value ADD Address of slave \001

ADS Address of master \000
NOB Number of bytes-1 2-1= \001
In Master->Slave telegram
FCN Function code F0h
PAR Parameter \000
BCN Block Count \001 (always 1)
NOB Number of bytes-1 3-1= \002
In Slave->Master telegram 1.

From what I can read in the manual, I think can create the above communication by entering in a regular scan schedule (on one line):

1SERIAL(RS485,"{\016\001\001\000\002\240\000\016\003\BCS} \016\002\001\003%b[14CV]%b[15CV]%b[16CV]\016\003\%b[17CV]")

That is, the bytes sent/received are DLE SOH \001 \000 \002 \240 \000 DLE ETX BCS DLE SOH 001 003 --read 3 data bytes - DLE ETX -readBCS.

After this, the received byte values (3xBCD + 1xchecksum) will appear in channels 14-17 (?).

(The checksum has yet to be calculated; I am not sure whether it is initiated with FFh or 00h, but that is not the issue here) I am aware of the double-backslash thing in DeLogger, just omitting it here for clarity. 2.

Is it possible to include the above (with possible changes) in any schedule, say one where analog values are read?

Best regards,
Peter
Engineering geology Lund university

Good afternoon Peter,

First up I would like to note that the DT800 is an ASCII device and is not set up for binary manipulation. It would be much easier if the device has an ASCII data mode.

I had a quick run of your code using a loop back to test the send / receive. With a couple of minor changes it does appear to work.

You are quite right about using the "special characters" () command.
The command \BCS is not valid, the \ command is for sending the char code for the ASCII number not the char itself.

Please try this code fragment.

1$="BCS"
1SERIAL(RS485,"{\\16\\1\\1\\0\\2\\240\\0\\16\\3\\%s[1$]}")
1SERIAL(RS485,"\\16\\2\\1\\3%b[14CV]%b[15CV]%b[16CV]\\16\\3\%b[17CV]")

I doubt if we can do the check sum. The XOR function is a logical operator not a bit operator. I will put in a change request for bit wise manipulation for engineering to consider.

Yes the code can be used in a schedule with other channel types. You will need to take into account the serial sensor port time outs and processing time.

Cheers,
Roger

Great, thanks for the answer.
I'll go and annoy some people right away

I was probably unclear about the checksum (BCS); it is really not a problem this time. The request I send is not changed between the polls, and so the checksum is static, and can be calculated in advance and coded as a byte. I just haven't done that yet. Sorry about the confusion.

As for the received checksum, it can be handled downstream, to the logger it will appear as any data byte.

About bitwise XOR: I think that being able to handle checksums would increase the logger's ability to more dynamically co-operate with PLCs, industrial "smart" sensors, marine instruments (NMEA) etc. From my experience the bitwise XOR is common in these environments.

Thanks,

Peter

A thought: Like it or not, the RS-232 serial port is the backbone of many instrumentation pools. An ability to address more than one serial port would make life easier. Maybe a buffered external serial port multiplexer controlled by, say, 2 of the logger's out ports and supported in the software as 2serial, 3serial and 4serial?

Good morning Peter,

Thanks for the feed back. I will pass it on to our Engineering and Marketing teams.

Your points about the RS232 interfaces are well taken but it's up the the crystal ball team to try and predict future direction. And I though Tech Support is hard enough

Cheers,
Roger

To the sound of screaming people, I today unplugged the DT800, and tried to use the serial port for binary comm, using Roger's advice, but substituting BCS for a checksum I calculated (15, initiate checksum with FFh) and changing the values for the CVs.

The DT transmits, but I consistently get the error "E73-\nnn too big", that according to the manual means "Special character code not btw 1 and 255". I do use (and have to use) NULL (\000). Is this not possible? In any case, NULL should not be too big!? Anything else that can go wrong? I mean - a byte can hardly be outside 0-255, so I am a little lost here.

Sometimes I have got the error E78 - Expecting %x[args]. I can not see anything wrong with the code - what should I look for?

The program:

DT=\d
BEGIN"JOB1"
CATTN
P31=3
RS1S
PS=9600,N,8,1,NOFC
RA2S LOGONA GA
12I
1SERIAL(RS485,"{\\16\\1\\1\\0\\2\\240\\0\\16\\3\\15}")
1SERIAL(RS485,"\\16\\2\\1\\3%b[1CV]%b[2CV]%b[3CV]\\16\\3%b[4CV]")
END

In Roger's lines of code, there was a \ preceding the last %; I am not sure of why (escape character?) and I have tried with and without it to no avail.

Any ideas?

Good morning Peter,

I have just run your code without error. (I tested on 4.02)
What version of firmware does the DT800 have?

Yes the DT800 does transmit the nul char (0). I tested that out yesterday to confirm it did. The problem I had is the the nul is a line terminator in C so you need to use a terminal program that can process the nul.

The other error was mine. Don't know how that crept in.

Cheers,
Roger

The version is 4.02.0001.

The terminal program can handle NULL characters.

The RS-485 counter is working OK using a 485 <-> 232 converter and another program (on a PC).

The logger is not available to me for a while due to ongoing tests, and we have solved (or avoided :-) the original problem by using a current loop output from the counter instead.

If and when I enter these dark corners of the DT800 serial comm again, I'll keep you posted. Until then, thank you for your quick and relevant response.

Peter

Hi,

It's me again, with the DT800 binary comm.

I just realized today, after another two hours with the unit, that I can get rid of the "\nnn too big" errors, and read binary data just fine. That is, if I not use the double slashes \ when specifying character values in the Schedules I write.

I have probably misunderstood what DeTransfer is (I thought it was the text window in DeLogger), but it apparently is not.

I.e., instead of writing (for triggering on ASCII 2, for example)

RB1SERIAL"\\2"
1SERIAL(RS485,("\\2%d[1CV]\\10\\13)

I write

RB1SERIAL"\2"
1SERIAL(RS485,("\2%d[1CV]\10\13)

and everything is fine. (Not the same instrument in the example as previously in the post, btw).

I'll try to get back when I have tried the original RS485-device with these new insights.

I must say that it is critical that Datatakers can take in digital data from transducers. These are my recent account situations:

1. My client insisted on using an Omron laser disp sensor. The sensor would display the reading on its own display. Now, LOGGING this data was a problem without increasing the uncertainty. This is because 0-10V or 4-20mA re-transmission had to be activated and the dual source of uncertainties crept in: resolution of the digital to analogue conversion and Datataker's analogue to digital conversion;

2. There are heaps of DPM (digital panel meters around) where the analogue signal from transducers are digitised, scaled and engineering readings displayed on the screen. Unfortunately, we cannot read the digital output from the DPM! In more fortunate cases, the sensor output is 4-20mA and putting both DPM and Datataker should do the trick. However, even in cases like that, there could be discrepancies as we are talking about two ADC's and scaling.

Could engineering and marketing consider adding digital DATA input to the features of Datataker products? After all, despite the signal conditioning, ADC and logic capabilities of the Datataker products, we are still primarily a data LOGGER and input sources are becoming increasingly DIGITAL.

Good afternoon CW,

We do read in digital data. That is what the serial sensor port is all about.

At the moment it reads in ASCII and high endian binary data over RS232, RS422, RS485 and SDI-12 serial interfaces.

The problem we face is that there are hundreds of different types of "Digital Data" interfaces out there.
Which ones do we support?
Which ones don't we support?

The serial sensor port is only part of the capability of the DT800 and because of ease of upgrade new features can and will be added.

We have to make commercial choice as to what we support and all this feed back helps us in our choices.

Cheers,
Roger