LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

modbus controls

Hi guys, I'm fairly new to Modbus and I'm having an issue with turning a device off an on over a modbus tcp connection over ethernet. This is a very simple code, so I'm not sure where the problem is or why it is behaving the way that it is behaving. I wrote a similar program to read the values from a nearby address and it is working perfectly. The "0" address is the control word address. 1150 is the stop/get ready command, while 1151 is the start command. Upon executing the code once, the vfd's start up just as they should and they are set to the appropriate hertz value, as they should. However, after changing the hz value and running the code once more, the vfd's turn off. Then, if i run the code again, they will turn back on and change to the hertz that I have set. In other words, on every odd run of the code, they are on and functioning, while on every even execution of the code, they will turn off. I understand that the issue is probably with the 1150 and 1151 write commands, but I can't wrap my mind around why this is. Any help at all would be greatly appreciated. Thank you! 

0 Kudos
Message 1 of 9
(2,799 Views)

Have you tried repeating the 1150 command just before the shutdown?  It looks like the code is currently assuming an implicit "stop" command within the shutdown.

 

The way your code is functioning, it leads me to believe that implicit stop doesn't take place.  The essential flow you have:

Create new TCP Master

Tell it to get ready.

Tell it to start.

Write the Hz value.

Shutdown.

 

On odd attempts, that works well.  But, if it's not running the stop, I wouldn't be surprised if the line is still acting as if it is in the "start" state.  When you run the code the next time, the first thing it does is stop.  Then when you run start is missed the "get ready" portion.

 

Is that something that sounds feasible or am I misunderstanding your stop/get ready and it's only the single state for your device?

0 Kudos
Message 2 of 9
(2,737 Views)

@BoKnows wrote:

Have you tried repeating the 1150 command just before the shutdown?  It looks like the code is currently assuming an implicit "stop" command within the shutdown.

 

The way your code is functioning, it leads me to believe that implicit stop doesn't take place.  The essential flow you have:

Create new TCP Master

Tell it to get ready.

Tell it to start.

Write the Hz value.

Shutdown.

 

On odd attempts, that works well.  But, if it's not running the stop, I wouldn't be surprised if the line is still acting as if it is in the "start" state.  When you run the code the next time, the first thing it does is stop.  Then when you run start is missed the "get ready" portion.

 

Is that something that sounds feasible or am I misunderstanding your stop/get ready and it's only the single state for your device?


Yes, that's exactly what I attempted after making this post and it didn't work. I would get the exact same result, which is very weird to me. Does it appear to you to be a problem with the labview logic, the modbus command, or possibly the device that I am trying to control? I mean I can't imagine it being the device itself unless there's some strange setting that needs to be changed but I can't think of any setting that would give me this result. Thank you for your help anyways.

0 Kudos
Message 3 of 9
(2,733 Views)

If I'm understanding your original post correctly, everything executes as you expect if you only try to work with one vfd.  Is that correct?

 

If so, have you tried testing with each of the vfd's individually to make sure they're all responding?  If all four pass, I'd have a hard time suggesting the device is the issue.  That would show each device responds to the commands.  It would also show the modbus library is performing as expected.

 

The next piece would be to debug the code to determine why we are seeing the odd/even behavior we are now.

0 Kudos
Message 4 of 9
(2,704 Views)

@BoKnows wrote:

If I'm understanding your original post correctly, everything executes as you expect if you only try to work with one vfd.  Is that correct?

 

If so, have you tried testing with each of the vfd's individually to make sure they're all responding?  If all four pass, I'd have a hard time suggesting the device is the issue.  That would show each device responds to the commands.  It would also show the modbus library is performing as expected.

 

The next piece would be to debug the code to determine why we are seeing the odd/even behavior we are now.


Since yesterday, I have tried controlling all four vfd's and all four are functional. I was able to split up the labview code into two different true/false cases which is essentially just an on/off switch between the 1150 and 1151 commands and everything works perfectly. However, my problem now is that I need to be reading the speed from one address constantly and then writing the speed to a different address whenever I choose to. In order to do this, I would need to be able to run it in a while loop, but I think that this causes a problem. I'm not sure if modbus reading and writing has a problem with being run continuously since I am very new to it, but I can't imagine that it wouldn't be able to do this. I will post my code so you can see what I'm talking about. Anyways, my read code works flawlessly on its own. When I try to run my write code, however, they both work fine for a few seconds, maybe up to ten at the very most. After this, I get a labview error code 60 that says

"Error 60 occured at TCP Open Connection in TCP Master.lvclass:Initialize Master.vi->Modbus Master.lvclass:Initialize.vi->API Main.lvlib:Create TCP Master.vi->true false write.vi

 

Possible reason(s):

 

Labview: The specified port or network address is currently in use. Select an available port or network address."

 

Now, I figured that this would maybe be due to running two different labview codes at the same time which were trying to access the same device at the same time via ethernet, so I only ran my write code without having the read code running and I got the exact same problem, so I know that the problem lies in the write code. I am completely stuck and don't really know what to do, so any help from anybody would be greatly appreciated.

0 Kudos
Message 5 of 9
(2,700 Views)

Sorry. Forgot to include my VIs

Download All
0 Kudos
Message 6 of 9
(2,699 Views)

Instead of constantly writing to the bus, I'd do something like this. I wanted to make something a bit prettier, but I'm not sure if you want to keep the IP addresses fixed or if you would prefer something more modular so you could change these on your Front Panel in later runs.

 

This should only call the write VI once.

 

You should be using a wait in your while loop to prevent the VI from taking over your CPU.  Making that change might also fix the error you're seeing.  Try adding in a 100ms wait and see if that helps.  I didn't add that into my changes, but I should have.  You'll know better how long you're willing to wait between each call than I do.

Download All
0 Kudos
Message 7 of 9
(2,672 Views)

@BoKnows wrote:

Instead of constantly writing to the bus, I'd do something like this. I wanted to make something a bit prettier, but I'm not sure if you want to keep the IP addresses fixed or if you would prefer something more modular so you could change these on your Front Panel in later runs.

 

This should only call the write VI once.

 

You should be using a wait in your while loop to prevent the VI from taking over your CPU.  Making that change might also fix the error you're seeing.  Try adding in a 100ms wait and see if that helps.  I didn't add that into my changes, but I should have.  You'll know better how long you're willing to wait between each call than I do.


Hi Jeff, it won't let me load your VI because I'm running 13.0.1. Is there any way at all you could post a 13.0.1 compatible version? Thank you

0 Kudos
Message 8 of 9
(2,663 Views)

Sorry about that.  I always forget to backsave when I don't ask which version of LabVIEW we're working with.

Download All
0 Kudos
Message 9 of 9
(2,656 Views)