Need help with read/write to MODBUS RTU registers in Labview 8.0

[Benji..]

Hi again Paul..

Just wanted to give you an report and to thank you..  You were right, the com port was blocked.. I searched in the task manager and find some applications.. and removed them, cause only Lookout had access to this port.. Guess what happen? I was not able to start up my system again.. so my solution was to delete the com port, cause I know that winxp will build it up again.. After that I had access again, and was also able to write from my modbus tester direct to my registers..

I tried this morning to write  01101001000102FFBFB600 and yes.. it happens what I expected.. ok

I wrote the value FFBF cause I didn’t want to activate an alarm in bit 10.. So it works..

No I need to find out how to read from the registers with VISA..  the problem here is the CRC check. I have tried to searched on internet and read, but so far I don’t understand how to calculate it..

I use only two registers in my MODBUS generator.. and that is FC03  and FC16  the other one is not of interest for me..  These registers starts at 100H and 1000H

I will try to solve this cause it’s the only way to learn and to know what is going on, but if you have any idea how to calculate CRC, I will be happy..

One more questions… what is the point with the DSC module??  Init of com port is ok, and the register addresses are ok.. but does it calculate CRC? Any idea??

I have tried for hours, but no luck.. and it seems like I’m communicating, cause all of them has a green indicator…  tips?

Thanks again..

Very best regards..

Benjii..

[falkpl]

As for the DSC module I have not used it (I am taking a seminar on it in a few weeks) but I have codod mosbus drivers with labview and visa from scratch.  Attached is a MODBUS CRC calculator, input your string excluding the CRC code and the output is the CRC and also the string with a CRC concatinated.  For rhe read remove the CRC you recieve, pass the rest into the CRC-16 vi and validate that the CRC is the same.  so a dricer is prety simple with visa. Open visa, fro commands with no reply, build the command string (function, address, data ...) add the CRC-16 code and send a visa write (If you plan to send multiple commands you need 1.5 Bits of wait between commands).  For queries send the command and then call a visa read with the expected number of bytes of the response, parse the string, get the data and verify the CRC code (This should not fail very often from my experience).  One other side note, if you use the newer DAQ/Visa drivers (DAQ8.0 +) there is a very nice feature, when you put a visa resource list control down, not only does it autopopulate this list but there is a little icon next to the resource name that indicates if the resource is currently in use.  Hope this helps.

Paul

[Benji..]

Thanks Paul....

I'll try my best.. Benjii

[unclebump]

The DSC module is used to read thousands of registers from plc's and opc servers in the background. The labview code then only reads the data out of the DSC system, it doesn't have to handle all of the modbus communication. Imagine your modbus code trying to read thousands of registers at a time. Each modbus command is limited to 100 registers in a read or write.

[unclebump]

The CRC calcuations should already be buried inside the NI modbus library. You should not even have to mess with trying to generate it yourself.

[Benji..]

Again.. thanks and thanks again..

I write to my Modbus register earlier.. so I will figure out how to do things..  Yes, Paul... the CRC calculation VI is in the NIModbus, but they didn't calculate the right values according to the one my MODBUS tester did..  But I find another one on internet, that calculate exactly the right values, and when I use that one, I wrote easily to my MODBUS Generator..

When it comes to the DSC module, I will try to study it more, and to see how it works..

Thanks... very best regards.. Benjii..

[falkpl]

Glad things worked out.  There is probably different modbus CRC algorithms (the one I posted is CRC16) The DSC module is worth learning if you are doing alot of MODBUS and industrial communications.  I usually am talking to one modbus per project and only a few modbus calls so I dont mind writing the drivers. 

Paul

[Benji..]

Thanks Paul..

Your CRC VI worked perfectly, just that I forgot to specify Hex in one place..  That's  all..

I both read and writes to my device now, so I have progress. I have a small system that I'm controlling.. or maybe not.. I don't know. I collect temperatures from 30 rooms in a high school, lightning, controlling 4 air condition systems and a burglar alarm system..

That means that I write and read status from my holding register which incude 6 16 bit's registers.. starting from 1000H. I read my PIR detectors in 2 registers which start at adress 100H and 30 registers that all include temperature values.. So I need to prepare a reasonable way to collect the values from my device, calculate and then write out to my device again. I have to study and find a good way to set up the whole system... but I think I will manage it..

Very best regards Benjii..

[Benji..]

Hi again Paul..

You helped me earlier about reading modbus register, and I have been working with that for a while, and it works fine now

Both reading and writing without killing my cpu..

As I maybe told you, I work in a high school, and I controlling about 30 rooms in the school, stiching on/off lights, controlling heating and controlling aircondition systems.. 

Now I have been working for a while to see how I can make this work in labview..

All rooms and airconditions systems has to be updated continuous according to changes in temperatures, light on/off etc..

I have been studying event structures for a while, but I am not sure if that is the way to go.. if you understand..

When I load all rooms as subvi in my main vi, it will take to much capacity from my cpu, so that is not a good solution..

So I wonder if you have any idea to build up this..  or to give me some hint?  

I have attached a file in my old system so you can see how it works in lookout..

Lookout works fine, but in labview I have much better control what is going on, and there is better ways to solve things in

labview..

If you see at the attached file, you see how how lookout works today, when I hit the pushbutton for ex. 107, the subvi for that room pop up, and I can make settings like increase temperature, or change when night set-back will occur..

So I try to find a way to control everything in a way that I don't kill my cpu...

Thanks...

Very best regards benjii

[Wiebe@CARYA]

This is the basic idea about how this is done (how we often do it anyway):


You need two loops, one for the hardware communication (DAQ), and one for the UI. These two loops can be implemented different ways. You can simply put two while loops on your main vi. Or you can make a UI vi, and start the DAQ loop dynamicly. Or have one VI start the DAQ and UI (dynamicly, or as sub vi's).


You need a means to communicate between them. Again, there are more that one way to do this. You can use Queues, user events (this is what I prefere), smart globals (a.k.a. action engines, LV2 global, buffer vi), or variables. You'll probably need more that one of these (e.g. a buffer and user events).


The UI will have an event structure. When the user presses a key, the UI delegates the action to the hardware. For instance, it sends a user event to the DAQ. This way the UI will take as few CPU time as possible.


The DAQ loop might be polling the devices. The data of each device is stored in the buffer VI. When all devices are polled (or as an option: after each device is polled), it sends an update message (user event). The UI then knows it needs to update it's values.


To stop the application, the UI sends a stop user event. All vi's that listen to the event will stop, inculding the DAQ and the UI itself.


If you keep to this system, you'll also have the ability to replace the DAQ loop, without altering the UI. Very usefull if you want to make a simulation for your hardware. And you can change the UI with a low level test application, without any effort. You can even have them both running at the same time...


It will be a puzzle to figure it all out, but you'll end up with a flexible, maintainable applcation.


Regards,


Wiebe.