Porter

Version 1.2.1 uploaded. It attempts to resolve a bug that we found in the VISA locking behavior implemented in MB_Master_Serial. See this forum topic for more information: https://lavag.org/topic/19871-visa-lock-behavior/ This version also adds a 10ms delay between retries in MB_Master_Serial "Querry.vi".

Just a personal preference. I am more familiar with the behavior of SEQs and the error codes that they produce. I could have used an actual semaphore though.

Yes. I usually forget to set the version number correctly because it such a pain to get to. I realize afterwards and have to re-build my application. Other features that I'd like to see: - Reentrancy, debugging, auto error handling settings for each VI (even if they are read-only) - For a class, it would be very useful if you could rename all of the object in/out terminals of member VIs with the click of a button

This is what I've come up with: VISA Lock Behavior Fixed.vi Dependency: Plasmionique Modbus Master I tested it over the weekend on one of our systems. I apologize for forcing the mb_master package on you all but the locking/unlocking code (MB_VISA_Lock.lvlib) was absorbed into it. This is what I'm doing differently: - Semaphore takes the name of the VISA resource from the Resource Name property instead of casting the session to string. - Semaphore reference is stored in the User Data property of the VISA session. Just need to keep track of 1 wire for a VISA session. - The Semaphore wraps the original VISA lock. That way we get the predictable scheduling feature of the semaphore but the safer locking features of the original VISA lock (supposedly it works over multiple LabVIEW application instances).

The reason why I am trying to do this is for code reuse, modularity and scalability. My system has multiple comm ports with multiple instruments on each comm port. For example, a Modbus temperature controller and a Modbus PLC can be on the same comm port. I have 2 very different labview drivers for these instruments. Their init/shutdown routines are different. The polling period is different. The data types are different. I would rather not spend the time to develop a non-reentrant wrapper to go around the read-write functions of these drivers. Besides that, what happens when I decide to move the PLC to a different comm port? I don't want to have to modify the source code and re-compile. It should just be a matter of changing a line in a config file.

I've implemented a workaround using names single element queues (essentially semaphores as ensegre suggested). So far it looks quite promising: My simulation code looks like this now: I will post the source code one I've completed some tests this weekend.

I am communicating with multiple instruments over a single serial port. These instruments are different but share a common communication protocol. Therefore, it makes sense to handle their data acquisition in separate loops. To do this, I open duplicate VISA sessions on the serial port (one for each loop). To avoid one loop interrupting the other's serial transaction, I am trying to use VISA locking: - I would expect one loop to take control of the serial port while the others wait in some sort of FIFO queue (implemented within the VISA lock primitive). - I would expect that if the timeout of the locks were set to 10 seconds, and there were 3 loops, each loop executing one serial transaction that takes less than 50ms, then the VISA lock should never timeout. In reality, this is not the case. It is actually possible that one loop can starve the others by somehow holding onto the lock over multiple iterations (See figure 1). The graphs show the amount of time (in ms) spent waiting on the VISA lock per iteration of the loop. Clearly loop 2 never has to wait while loop 1 and 3 timeout after 10 seconds. Figure 2 shows a case where the loops are not starving each other but are clearly holding on to the lock over multiple iterations before releasing it. My simulation VI is attached. COMM time is the time in ms allotted to each serial transaction. Poll period is the desired execution rate (in ms) of the loop. Starvation starts to occur when COMM time is equal to poll period. Note that I am not using "VISA Lock Async" because it is NOT re-entrant and is thus only appropriate if your system only needs to use one serial port at a time. I really didn't expect this kind of behavior. So my question is, does anyone know why VISA lock has been implemented this way? VISA Lock Behavior.vi

Great work! I've been using this tool for a couple of months now. I'm looking forward to trying your next release. So far I've found it most useful for editing the inheritance and localized names of my classes.

Thanks! My quick-drop plugins were all messed up. I had installed some unofficial plugins that took over the "Wire multiple objects together" shortcut. Successfully restored it by copying the default plugins from another machine. This shortcut will save me hours of tedious wiring.

Is there any way to automatically wire an index array block to a bundle by name block? Auto-wire (pressing space) just adds one wire. Note that my cluster contains data of different types so converting the cluster to an array doesn't work. If there is a quick-drop shortcut for this I would be very impressed.

You can create a copy of the MB_ADU_RTU class and replace the Calc CRC-16 with whatever check that you want to do. You will probably also need to modify the RX ADU and TX ADU. After that, you should create a copy of MB_Master_Serial class and modify Open Serial Session to use your new MB_ADU_RTU class as its ADU. You can then use the function code vis on your new MB_Master_Serial class to communicate with your slave device. Let me know if you come up with a better way of doing this. I don't like creating copies of classes but this avoids modifying the original library.

Perhaps they had the intention of allowing longer length responses at some point. According to the spec, Read FIFO Queue is limited to a maximum byte count of 64. The MSB of byte count will always be zero. This is just a little annoying though since the byte count parameter for any other function code is only 1 byte long.

Version 1.0.5 uploaded. Does anyone know the reason why Byte Count of Read FIFO Queue (function code 24) is 2 bytes long?

New version uploaded (V1.0.4). Now supports function codes with responses of unpredictable length in RTU mode (other modes already supported this). In RTU mode, if the RTU_DataBytes is set to less than zero, RX_ADU.vi expects that, in the response, the byte after function code is the number of data bytes. However, if the function code is 43, Modbus encapsulated interface transport message format is assumed. For now, only MEI type 14 is properly supported. Other MEI types rely on a timeout of 200 ms to determine the end of message.

OK. I've worked it out. Modbus Master now has a dynamic dispatch accessor for ADU and Session Valid. I'm going to make an example for a TCP/Serial device this weekend and post an update.

During development I was using the RX/TX data and timestamps for debugging purposes only. I didn't really intend to expose them to the top level. I will look into creating accessors for them in the parent modbus master class. I'd rather not have the parent ADU class in the parent modbus master class though.

Error code -8101 means that the Slave ID of the RX message doesn't match that of the RX message. Error code -8102 means that the CRC of the RX message is invalid. I'd suggest using a different USB to serial converter. Otherwise, you could try increasing the number of retries.

Was it the "VISA Set I/O Buffer Size" that solved the problem?

The main difference that I see is that the I/O buffer sizes are set to 4096 before the first VISA write. I suspect that they are doing this because of the problem described here: http://digital.ni.com/public.nsf/allkb/60DDFED7EFEFE7188625705700750821 You can add "VISA Set I/O Buffer Size" to the "Open Serial Session.vi" of the Modbus Serial Comm Tester (located in the init case). I imagine that this would have a negative impact on performance so you should increase the timeout to 1000ms. Also it looks like they use function code 4 to read address zero. So you should try using "Read Input Registers" to read register zero.

Here it is for LV2012. Note that it is included with the Plasmionique Modbus Master package. You should be able to find it in LabVIEW's "examples\Plasmionique\MB Master\" directory. MB_Serial_Master Comm Tester.vi

For convenience, I'd recommend trying the MB_Serial_Master Comm Tester (attached). You can try with different serial port settings and register addresses. Once you find the winning combination you can put it in your code. To use: - Run the VI - Set the Communication Settngs: COM1 or COM3 or COM4 (whichever is connected to the instrument), Baud Rate 9600 or 19200, Address 1, Mode RTU, Stop Bits 1.0, Flow Control None, Parity None - Click Open Port (The LED should turn green) - Set starting address of Holding Registers to 0 (also try 1), quantity 1 - Click Read Registers If this produces an error, the serial port will be closed automatically. MB_Serial_Master Comm Tester.vi

Thanks for taking the time for review my code! I was originally thinking about doing something fancy with the PDU inside of the ADU but decided that it was better to let the PDU deal with itself. I agree there is no reason to have it in the ADU class. The simplification that I made to the RTU serial read was to cheat by having the "build PDU request" function calculate the expected number of data bytes of the PDU response. This way the RTU serial read procedure doesn't depend on timeouts or the function code. The downside of this is that when implementing new function codes, you need to remember to set the NumBytes parameter of the PDU request properly otherwise RTU serial read will not produce the expected response. This is why I was tempted to encapsulate the PDU in a class instead of a cluster. However, to make it easier to add functionality, I agree that it's a better idea make the PDU a cluster. Implementing a new function code is simply a matter of creating a VI that calls Querry.vi with the correct parameters. I've prepared an update with the following changes: Converted MB_PDU class to cluster Removed RTU inter-frame wait time optimization in TX ADU. It may have caused problems when sharing the serial port. Renamed NumBytes of MB_PDU to RTU_DataBytes Split interpret response VI of PDU into 3 VIs to handle different message types Set build and interpret VIs of PDU to private Removed function VIs from MB_Master class Removed PDU_req and PDU_resp from the MB_ADU class

View File Plasmionique Modbus Master This package contains the Plasmionique Modbus Master library for LabVIEW. It supports RTU, ASCII and TCP modes with the following function codes: 0x01 - Read Coils 0x02 - Read Discrete Inputs 0x03 - Read Holding Registers 0x04 - Read Input Registers 0x05 - Write Single Coil 0x06 - Write Single Register 0x07 - Read Exception Status 0x0F - Write Multiple Coils 0x10 - Write Multiple Registers 0x16 - Mask Write Register 0x17 - Read/Write Multiple Registers 0x2B/0x0E - Read Device Identification Other features include: - Sharing a COM port across multiple Modbus sessions using VISA locks (10 second timeout). - Sharing a Modbus session across multiple communication loops. - TCP transaction ID handling to ensure that requests and responses are matched up correctly in case responses are received out of order. - Modbus Comm Tester, available through the "Tools->Plasmionique" menu, for testing communication with a slave device without writing any code. - Detailed help document available through the "Help->Plasmionique" menu. Examples are included in "<LabVIEW>\examples\Plasmionique\MB Master\": MB_Master Comm Tester.vi: Demonstrates usage of API to open/close connection and communicate with a Modbus slave device. MB_Master Multiple Sessions.vi: Demonstrates usage of API to open concurrent Modbus sessions. MB_Master Simple Serial.vi: Demonstrates polling of a single input register over serial line. Download a copy of the user guide here: MB_Master - User Guide.pdf Note that Version 1.3.4 of this library has been certified compatible with LabVIEW and has been released on the LabVIEW Tools Network: http://sine.ni.com/nips/cds/view/p/lang/en/nid/214230 The most recent version of this library will always be released on LAVA first before going through NI's certification process. ***This project is now available on GitHub: https://github.com/rfporter/Modbus-Master Submitter Porter Submitted 04/01/2016 Category LabVIEW Tools Network Certified License Type BSD (Most common)  

Reproduced on LV2013. See attached VI. Changing the Y-scale of the plot during run-time should reproduce the problem. It seems that the cursor's y-scale is not updated until you move the cursor manually. A workaround is to catch the plot attribute change event and update the cursor list manually. I've implemented this in the attached VI. Enable the Fixit? button and then change the plot's Y-Scale and the cursor should snap to the correct scale. The attached VI is saved back to version 2011. Let me know if it works for you. Ok... I can't attach files... Here it is in dropbox: https://dl.dropboxusercontent.com/u/8640811/XY%20Graph%20Bug/XY%20Graph%20Cursor%20Test.vi