LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Shimaden Protocol / SR93

Hi,

 

Has anyone been working with Shimaden protocol? or has communicated with their digital controller units (SR90 series)?

 

Regards

0 Kudos
Message 1 of 10
(3,181 Views)

Is there any reason why you have to use the Shimaden protocol? If not, use the MODBUS protocol.

0 Kudos
Message 2 of 10
(3,152 Views)

Yes, that would be ideal. Do you have experience how to change that? I have tried connecting using modbus but I'm getting timeout.

The Wire Mode property on the Modubus connection is RS232/DTE and when I try to change it to RS485/Wire2-Auto an error is generated saying that this setting is not available.

I see that on the controller there is a Prot(ocol?) setting that has 3 options Shim/ASCII/RTU. I would assume that it has to be changed to RTU (or ASCII)?

Anyway here are the controller settings that I think are relevant in this case:

Data: 8n1

Start char.:STX

BCC: 1

BPS: 9600

Delay: 40

Prot: RTU (Shim initially)

 

Attaching the program I'm using  (LV2018).

All suggestions are appreciated.

 

Regards

 

0 Kudos
Message 3 of 10
(3,114 Views)

I never used a shimaden controller, but similar devices and I always used modbus RTU and in most cases with no parity, 2 stop bits, 8 data bits. Some drivers may use incorrect settings for the stop bits. Do you have the communication manual? The SR93 has 9 parameters related to the communication. Mode (I don't know, what this means, Com seems to be what you need), Protocol (rtu), Address (your choice), Data format (8n2), start char (STX), BCC (not used for modbus), rate (19200 bps), delay time (start with the default of 20 and reduce it later), also the memory mode seems to be important for some applications (I would prefer: Ram).

0 Kudos
Message 4 of 10
(3,111 Views)

@Niklasson wrote:

Anyway here are the controller settings that I think are relevant in this case:

Data: 8n1

Start char.:STX

BCC: 1

BPS: 9600

Delay: 40

Prot: RTU (Shim initially)

 


You can also use these settings. I think you are using an older labview modbus driver (stop bits setting is incorrect for parity none). If you use parity even, it is ok. Also take a look at the communication mode and try the two different settings).

 

You are using "Read Input Registers" in your VI. This is wrong. The device only understands MODBUS function code 3 or 6. You can use only "Read Holding Register" or "Write Single Register". all other options will fail.

You are using address 0 which is wrong (only 1 to 31 are allowed (check the device settings).

And use address 0x100=256dez to read the measured value.

Use a larger timeout value - maybe 1000ms

And for the beginning, read only one register.

 

The device should return 200 for for 20.0°C as explained on page 20 of the communication manual.

 

0 Kudos
Message 5 of 10
(3,103 Views)

You are using "Read Input Registers" in your VI. This is wrong. The device only understands MODBUS function code 3 or 6. You can use only "Read Holding Register" or "Write Single Register". all other options will fail.

Read Holding Register fails with modbus exception code 2 - Illegal data address

 

You are using address 0 which is wrong (only 1 to 31 are allowed (check the device settings).

I assumed this is the address in device memory where data is stored? In my previous Modbus project the address 0 + Read Input Register worked fine.

 

And use address 0x100=256dez to read the measured value.

Would that be as a starting address for the register?

 

I have downloaded manufacturer's software and can connect to the units with the settings I have on them i.e.: Modbus RTU/speed 19200/parity none/stop bit 2. The same settings in LabView generate timeout.

I have used both old modbus and new from VIPM ver 1.2.1.42 - the results are the same - timeout.

Just in case I have also checked Parity None/Even settings with no effect.

 

0 Kudos
Message 6 of 10
(3,091 Views)

Difficult to say, what's wrong with your code.

There are some examples in the manual (page 19 - example (2) RTU mode)

I modified your VI to transmit this command (Reading SV value from subordinate device No. 1). If your device has addess 1 you can send this command. The driver exactly transmit the bytes 0103 0300 0001 844E (also decribed in the manual). This should work. If not, then check the communication parameters and if you did not find anything, then check the communication parameters again 🙂

 

0 Kudos
Message 7 of 10
(3,078 Views)

snip.png

I forgot the attachment ....

0 Kudos
Message 8 of 10
(3,077 Views)

Don't use that Modbus Serial Init subVI.

 

You said in a previous message.

"I have downloaded manufacturer's software and can connect to the units with the settings I have on them i.e.: Modbus RTU/speed 19200/parity none/stop bit 2. The same settings in LabView generate timeout."

 

If you open up the Init, you'll see it hard codes in 1 stop bit.  But you want 2.  (This is one of the bad parts about this library is that it made assumptions on the stop bits.)

 

Replace the INIT with a regular VISA Serial Configure, and it should work just fine for you.

Message 9 of 10
(3,042 Views)

So apparently it was a mix of few things, not using the Modbus Serial Init and reading holding registers being the two main issues here.

Thanks for the guidance 🙂

 

0 Kudos
Message 10 of 10
(3,024 Views)