LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VFD - Visa

I  did, but I got the warning 1073676294, which led to an error from the master query.

Btw, for the VISA VI, I just fixed that same warning for VISA read; I found out that one of the connections wasn't wired, but then when I fixed it and I ran it, I got an error saying that the resource is valid, but VISA can't access it. Not anymore.

Edit: Not to mention the output in read buffer before the error message occurred was gibberish.

0 Kudos
Message 31 of 46
(1,577 Views)

Update: I got an error on the VISA read this time (-1073807298), and i don't know how to solve this. I made an Modbus I/O server that set up the baud rate at 9600, 7 data bits (I'm trying to send ASCII commands this time rather than RTU), and left other options as is. The VFD is set to "Modbus Communication", I changed it so that the data format is 1-7-2-N, format ASCII (from default 1-8-2-N, format, RTU), and I'm using a RS485/RS232 adapter (VFD is also set to direct communication (RS232/RS485)).

0 Kudos
Message 32 of 46
(1,557 Views)

Hi chromatic,

 

does your VFD support 1-7-2-N? Both ends of a serial communication have to use the same port settings…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 33 of 46
(1,546 Views)

Yes it does. I also checked the port settings and changed the data bits value from 8 to 7. I thought that would solve the problem, but I still get the error.

0 Kudos
Message 34 of 46
(1,541 Views)

I want to make sure; my command shouldn't have these boxes in it when executed, right?

One other thing. In my I/O server, I left the address as 1, but the broadcasting address for the VFD is 0. If my I/O server was supposed to have the address set to 0, how would I go about changing said server?

0 Kudos
Message 35 of 46
(1,527 Views)

There is nothing wrong with those boxes you highlighted in those strings. They are just place holders for bytes that are non-printing characters in the ASCII table.

 

When doing modbus, you should not have the termination character enabled.  Modbus messages are binary messages can have any byte be a part of a valid datastream and not mean it terminates the message.  And if your message never has the termination character, it will probably timeout before it reads the 5000 bytes you are asking it to receive.  The odd thing in your string to write is that it is adding a CR LF to the end of it which is not valid for a modbus RTU message.

 

You really should be trying to use the Modbus library rather than trying to do this on your own.

 

That said, I don't know why your VISA read is getting that error code which just says I/O error without further details.  It must be something wrong going on with the serial port drivers.

 

As for the address, I don't know exactly what you mean by "broadcasting address for the VFD is 0".    Modbus uses address 0 only when it wants to send data to all devices on the bus, and it cannot receive any response back.  Any normal slave device should be in the range of 1 to 247.  So you should read the manual to figure out how to make the slave address for your device one of the valid numbers.

0 Kudos
Message 36 of 46
(1,521 Views)

Nvm; slave address was at 1. I/O server is correctly set up, as far as I'm concerned, but again, I was trying to send it ASCII commands, since the transmission mode for the server is ASCII rather than RTU.

Edit - it occurred to me; when trying to change the vfd parameters such that it would have a direct connection via cable (RS232/RS485) to my laptop, I believe I may have changed the baud rate instead. While I believe I have been getting errors in my VI even before changing the baud rate, I will set the proper baud rate tmrw (I can't work on it anymore until tomorrow), run the VI again, and provide you with any updates.

0 Kudos
Message 37 of 46
(1,517 Views)

If you are set up for ASCII commands, then the boxes in the string wires are wrong because they are binary bytes, while an ASCII string shoud basically look like 0-9,A-F. 

 

For example, if the byte value you are trying to send was decimal 77,  it would look like the letter "M" for RTU mode, but would look like "4D" in that string for ASCII mode.  Make sure your string control is set for the proper display format.  If you were doing RTU mode, the string should be set for hex display so you can type in 4D (a single byte).  If you are doing ASCII mode, then set it for normal display so you can type in "4D", (a combination of two bytes that is ASCII character 4 and the ASCII character of D.

 

Good luck to you in your tests tomorrow.  You will be able to figure this out.  Just make sure you understand decimal vs. hexadecimal, normal display vs. hex display.  And read up on the documents at www.modbus.org if you haven't seen them already.

 

 

0 Kudos
Message 38 of 46
(1,508 Views)

Thank you. So just to be clear, let's say I want to test out the ASCII command presented in pg 123 of the manual. That means I were to leave out the frame trail, convert the highlighted code into ascii, which in this case is 3a 1e 1f 1e 24 1f 1e 1f 1e 2e 29 1e 22 21, put that in the string (normal display) for the write function, and execute the VI so that the VFD will respond?

0 Kudos
Message 39 of 46
(1,501 Views)

With what you show, when using ASCII mode, the stuff that shows on the character line is what you put into the string set for normal display.  Ignoring the header which has a value of  ":", and that seems to be something that this device wants that I haven't seen in other devices for ASCII mode, you'll see that all the values are 0-9,A-F, and the ending CR LF.

 

If this was RTU, you'd be entering 05, 06, 02 , 01 (though I'm not 100% sure how they numbered there registers, it might be the U16 equivalent of 201), then 0F, 0A, then a checksum.

0 Kudos
Message 40 of 46
(1,533 Views)