MODBUS

[Peter M]

Hello,

Is anyone using HTBasic to talk to modbus devices?

If so, I would appreciate any advice you can offer to help me get started.
I’m a long-time HTBasic user but up to now have only used IEEE488 for IO.

Thank you,

Peter

[Mark Thuer]

Hi Peter<

I don’t believe that HT Basic has native support for Modbus. You can download Modscan if you wish to communicate with a Modbus device (serial/TCPIP). You can also download Modsim if you want to simulate a Modbus device. Both s/w packages are usable on a free trial basis and are very inexpensive to purchase outright. You can also use Python and the pymodbus protocol stack vs. HT Basic.

Mark

[Peter M]

Thank you, Mark, for your prompt reply. Most helpful. I do have a little modbus A-D RTU card and an RS485 card for the PC on which to test the actual modbus protocol, but Modsim looks to be worth a try and may well get me going rather quicker.

Meanwhile, let me disclose a particular issue here.
The ABB gas analyser from which I want to log data returns IEEE754 32bit data over modbus.
I am struggling to find an elegant way of converting the 32 bits, received as 4 bytes, to decimal.
I would appreciate any advice on this particular challenge!

The analyser is a replacement for just one of a number of analog instruments which we read using the HP/Agilent/Keysone Data Acquisition & Switch Unit 34970A with HPIB communication, so it would be very handy to solve this within the HP/HTBasic code which has run our system since 1989.

Thak you once again.

Peter

[Mark Thuer]

Peter,

What’s the exact model number for the instrument?

Thanks,
Mark

[Peter M]

ABB Easiline EL3020.

I am working from the documentation here

It has analog and modbus output, Mark, but the analog output is more noisy than the modbus output, presumably due to lower prescision the the D to A converter. A colleague has been able to log modbus data (using Matlab, I think) for comparison.

I am progressing a little with the extraction of data from a 32-bit dummy string in IEEE574 format.
Along the way I have been rather surprised to find that IVAL does not work with long integers!

Thank you for your interest. It is helpful to be able to chat about this.

Peter

[Mark Thuer]

Hi Peter,

I began using the HP 9826/9836/9845 and HP 9000, series 300 controllers back in 1980. Those were the instrument controllers of choice for Aerospace and military test stations designed around the HPIB (IEEE-488) and Rocky Mountain Basic (RMB). As personal computers matured in the late 80’s, HT Basic and generic HPIB card’s phased out those expensive HP controllers without the need to port the RMB software. This was a major advantage at the time. In the early 90’s, NI LabView became the new PC based software standard for instrumentation control and data acquisition. For your application, the least expensive port would be to use Python. It has native HPIB and Modbus drivers all for free and fully open source supported. With a minimal PC setup and USB HPIB interface ($100/eBay), you probably could port the RMB software over with a minimal effort gaining a much longer system shelf life.

For the first 20-years of my career, I designed and programmed ATE test stations for military and aerospace. So, I am very familiar with HP RMB, HT Basic, NI LabView and IEEE-488 I/O. The last 10-years of my career has been with a major water utility integrating instrumentation using proprietary SCADA software for control and data acquisition. Much of this instrumentation uses Modbus over RS-485 & IP.

Given your situation, the fastest way across the finish line would be to use the existing HT Basic controller setup and connecting the analog signal out from the ABB EL3020 to the A/D input of the HP 34970A. This eliminates your Modbus programming issue. With regards to the instrument signal noise/accuracy issue: 1) Set the full scale (F.S.) output of the analog signal to the lowest maximum measurement value needed. For example, if the instrument measurement F.S. is 10 “units” but you only need to measure 1 unit max for your application then scale the analog signal output F.S. for 1 measurement unit max. 2) Take an average of multiple readings that best represent the desired instrument display and/or digital reading. 3) You can also introduce an RC filter network across the output signal to further attenuate any signal noise.

With regards to capturing the serial Modbus data and importing it into HT Basic. Unless your job is dependent on you successfully implementing that approach – I would abandon it.

I hope this helps.

Mark

[Peter M]

Hello again, Mark.

Thank you for your advice. I apologise for the delay in replying.
I agree with you that the quickest way is to use the analog data from the analyser – everything is already set up to do that and it works well. The shortcoming is that the limited analyser DA precision means that we can see digital steps in the analog data. These are at the level of resolution we want to achieve in our measurements. When we look at the modbus data (not in HTB) we do not see these. A simple low-pass filter is of limited value when the noise on the signal is not continuously varying. When we look at the higher precision of the digital signal available through modbus then we can resolve changes in analyser readings at the level we require wihout seeing the digital steps.

I have spent many hours trying to get at the modbus communications through HTB with, so far, limited success. I have generated a modbus request string which I believe is read by the slave device but I have yet to receive a reply from it. Progress is limited by not being able to get HTB to load a virtual com port so I can’t get HTB to talk to a modbus slave simulator to see exactly what is going on.

I think my next post should be to look for help with virtual com ports – (I have com0com installed) – perhaps someone knows of one which HTB will be happy to talk to.

Thanks once again.

Peter

[Peter M]

An update!

I do now have the com0com virtual serial port working!

On we go!

Peter

[Author]

Posts