Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 03/16/2016 in all areas

  1. Use Read From Spreadsheet File.vi twice, once for each file. Index out first column of both resulting arrays, build new array using "Build Array" primitive. Probably you need to Transpose as well. But if the time stamps are to be connected to the measurement values, which looks to be the case, I would bundle each time stamp with the corresponding measurement value into a cluster and then have a 1D-array of those clusters.
    1 point
  2. "Shared Clone" reentrant subVIs are assigned to a callsite from the pool of free (not currently being run) clones *at the last minute*. This means that generally if you go click on a callsite, LabVIEW can't possibly know which one will actually be run by the caller VI, so LabVIEW just opens the "master copy". However, if that callsite DOES have an assigned clone because the clone is running exactly when you click on the callsite, then LabVIEW can open the right clone! This can be very hard to do unless the subVI takes a long time to run or you are already debugging thanks to hitting pause or hitting a breakpoint or stepping.
    1 point
  3. See this new video on youtube. I modified the demo so that 'Instrument' is running on a separate project behind a TCP server, with 'Top Level' connecting as a client via a Remote TCP Messenger. I also showed the use of an 'Address Watchdog' to shutdown 'Top Level' if ‘Instrument' disconnects. Here is the code (start the server first): Messenger TCP Server.zip Messenger TCP Client.zip I think I forgot to mention it in the video, but note that the Client project does not load the code of “Instrument", and the Server Project does not load the "Top Level" code. Thus, nothing is locked and you can edit freely (this is a problem in some architectures). This is done internally by the TCP server/client actors by keeping all reply addresses in flattened form on the remote target. If you use custom probes you will see most replies or registrations become something like "Route back to QueueMessenger and then to Flat", which is confusing but means "send back to the TCP actor running this connection, then via TCP to the remote system, and then to this address (unflattening it first)". Please note that only Reply Addresses are converted; you cannot send an address as data in a message and have it work on the remote system (attach it as a Reply Address instead). Please note that I have yet to do a Real-Time project with Messenger Library. I do have a current project using modified TCP actors to communicate with a non-LabVIEW client from another developer (using JSON messages), but that isn't the same. So please don’t be afraid to ask for help or to make suggestions. Please see if you can run this example with ‘Instrument' on the Real Time system. -- James Actor Manager for this TCP example. Note that the 'Control Server' actors are entirely unmodified, and have no knowledge that they are talking to 'Instrument' via TCP. Because everything is by message (no DVRs, no Action Engines) it is easy to convert things to remote operation.
    1 point
  4. If you ever think of taking a dip into .net drawing here is some example code (LV2013) to get you started... Forgot to mention that the example drawing vi is in the Test Folder AntiAliased Drawing.zip
    1 point
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.