drjdpowell

Opps. I had made it %,; as a way of testing it on my machine with strings like "123,456", but I forgot to switch back! Edit> added 1.2.7 version; please test

Sorry about that. I had put %.; in the array functions but forgot the scaler ones. Edit> please try the 1.2.6 version just uploaded.

In the end I found I could support both methods as an option: a "strict silence framing" mode where there must be a long silence (30ms+) in front on the message (to allow me to be sure there is a silence and clear the buffer) and a faster mode that uses pattern matching (but has a very small chance of deterministic failure if other slaves share the serial line).

I've been experimenting with different ideas all day. I can't seem think of a way to avoid all possibility of a deterministic failure. Non-deterministic failures correct themselves when the Master retries the command, but a deterministic failure (such as a long message to another unit that by chance appears to contain a shorter message to us) will reoccur every time. I can rely on "silence" for identifying the end of a message (since the Master is waiting for us to respond), but I can't identify the start except through pattern matching the message.

How many of you have done Modbus Slaves (rather than Masters)? Master communication is easy, as you just clear buffers, send command, and wait for response in known format. Retry on any failure. Slaves must listen to a stream of messages to multiple units, including unknown formats. My experiments with 3.5 byte silences are going poorly (30% failure rate).

I imagine there is no real problem with non-broadcast messages, since the Master will wait for a replay much longer than 3.5 characters, but it would be a problem with broadcasts (as the Master expects no reply and could send several broadcasts with only a short delay between).

My reasoning may be wrong but I rejected: 1) NI implementation as it is part of the DSC and requires a runtime license on each unit. 2) NI Labs free version because it is both unsupported AND password protected (a deadly combination). 3) Modbus Master by Plasmionique because it doesn’t do Slave/Server (though I’m using it as a guide). 4) Old NI library because it is very old. Unsupported for more than a decade (and it was very old back then). Also, it may seem strange to say, but these libraries aren’t solving enough of my problem. Building and parsing strings is the easy part; Modbus isn’t that complicated. It’s shoehorning my complex data into a bunch of U16 registers that seems harder. I think the above solutions maintain internal models of these registers, which I must continually update. Instead, I plan to do an event/message-based solution where I build the command responses directly from the application data.

The problem with that is that the instrument could be on a multi-slave RS485 line, with units from other manufacturers that may implement function codes (including User-defined codes allowed by the Modbus spec) that we don’t understand and thus can’t identify the end of. The advantage of the “silences” is that it is independent of message content.

I'm working on a Modbus Server (aka Slave) implementation for Serial communication. Has anyone experience with this? My immediate question is about the "RTU" format. Standard serial format uses CRLF characters to mark the end of messages, but RTU uses "3.5 characters of silence" on the serial line. I have no idea how to detect "silence" in a reliable way. Past Modbus in LabVIEW implementations I've looked at seem to put waits in to create silences, but don't use the silence for defining a received message. I am worried that this is vulnerable to error.

You should see if the next function along can be easily made to work with Array-of-Variant in place of Variant Cluster. Most of my subVIs that take Variant Clusters convert internally to Array-of-Variant form anyway (using the Variant to Date primitive).

It should be possible to update the OpenG VI, but why are you working with such a monster as a 997-element cluster in the first place?

I think your hitting one of the limits of the pre-8.0 type descriptors that OpenG uses.

Cross post from NI.com. Has anyone else had a problem with building an application were the window hangs and looks like this: Says "Initializing build. This could take several minutes...", but also has the "Done" button available. LabVIEW is not using any CPU in this state. Hitting Done (or Explore) exits the dialog, but LabVIEW is completely frozen and must be hast-killed from the Windows Task Manager.

Can you attach an example VI that shows the problem? I can then debug the issue.

I don’t know why the system buttons are also in the “classic” palette, but they are the same controls as in the “system” palette. BTW: If you use the non-system buttons you’ll lose the mouse-over “hover” effect (which, personally, I like a lot). You can instead customize a system button by swiping the change-with-the-os-shapes for regular rectangles or simple PNGs (such as the buttons in Flatline Controls).

System controls are supposed to change to match the operating system. Are your two machines on different Windows versions?

A Windows Restore revision fixed my initial issue, whatever it was. Then I got to work debugging a second issue in building, which turned out to be the very VIM issue you are talking about. I was able to identify a workaround (posted in your link), which is to delete the "Help path" to the extended documentation. If your VIM don't have extended documentation, then I think you are OK. The bug involves VIMs, extended help, and at least one other issue that I could not identify (builds of simple exes don't exhibit the issue).

What problems have people been having with LabVIEW 2017. I currently have the problem that it freezes on trying to open any project (including creating a fresh one). This is the second serious issue I've had (after this).

The Messenger Library TCP stuff uses service names (and thus requires the Service Locator). Let me know if you need to specify ports instead and I could add that as an option.

They’ll be in the next release, but you can use them directly from the VI.

I’m also considering removing the “Section Cluster” stuff, to reduce the API to support.

Is any early adopter using the “From JSON Text.vi” polymorphic vi (or its individual instances)? I want to completely deprecate those in favor of only using the “From JSON text.vim” malleable VI. Also, is anyone using any off-palette subVIs? Because I’m about to reorganize them and make them all private.

How about these? New Flatline mods.vi

Try from different site. —> uploading images works. So it must be something to do with my home internet connection.

Test from different computer. Both are Macs; I've also tried a Windows 7 in a VM. Seems to be the same issues.