ensegre

Would this do, then? The assumption is that the first column of the line is the pin number, then further columns can only be ON, OFF, a waiting time in ms or empty to end the sequence.

If you want something complex, you need to write a complex program which parses each line of your spreadsheet file, and and controls all the possible execution options accordingly, there is no escape from that. For example do you want to write pin-status-wait-status-wait-status-wait... or pin-status-wait-iterations... Maybe you should start there, defining what is to be expected on a line, and what is intended to happen; then you can think at possible implementations which satisfy your constraints. I don't even understand, should the lines of your file be executed sequentially or simultaneously? The examples above assume sequentiality; I previously deleted a reply of mine in which I was answering you understanding simultaneous start of all pin cycles, then thought that perhaps it was not the case.

Several ways. Two for example: in edit mode, click twice on the eighth button, which populates the array. Left click, Data Operation->Make current value default, Save VI.

I see. Yes, maybe someday I'll play and will put together a tool of my taste. Indeed I see that to get odd vi properties is not difficult; I quickly put together the following as a proof of concept without bothering for recursive descending of the project hierarchy and item discrimination, maybe on some rainy day.

I was wondering -- I would be curious to get full metrics for my latest project -- including not only number of .vi, .ctl, .lvclass (these I can grep from the file list, or from ls -R * |grep \\\.vi | wc -l ), but also number of global variables and where used, list of unused project items, optionally some complexity metric for all vis, which vis are password protected, which are on which execution system, and whatnot. I suppose that it would be possible with a bit of effort to put together a script for that, but is there out somewhere something ready made?

I would be looking at something related to <lvdir>/resource/dialog/PreferencesDialog/PreferencePages/prefPage_Misc.vi, but haven't yet figured out what.

I just ran into this oddity, which might lead me to revise a little a logger of mine. Now, I know of two easy ways of getting a number of seconds from LV: The doc is not too eloquent about the high resolution one and its cross-platform implementation, it only says "with 14 digits of precision after the decimal separator". Which would imply, if the representation is double, a span of only something like 100 sec, and this seems not the case (something like 14 significant figures and us resolution instead might be it). What is a quirk is that, if I convert the numbers in linux I get exactly the same time of the day, just a difference of 66 years and a day, not under windows, at the very least on just two machines I have tried. Hence under linux I could use the high precision timer to provide an useful 24h clock too, under windows not. The doc warns that the former is "relative" and "short time", true. I think I remember some discussion about, haven't searched yet. I think I was sort of aware that the two OSs use a different time structure for storing the system clock, which is probably exploited differently. ETA: yeah, https://lavag.org/topic/16198-timestamp-behavior/#entry98843 and http://www.ni.com/tutorial/7900/en/ , but they don't explain the 24107 days difference. ETA2: uhm, 1/1/1970 - 1/1/1904 = 24107 days...

If your instrument talks modbus (you say), then you have to talk modbus to it. This has little to do with the programming language. I attach a snippet of mine which I've used in the past to check basic communication using the library referred above, hope it helps. ModbusTester.vi

Shaun has given you the link. What seems that is unclear to you, is what is involved. Modbus is a communication protocol. A way do do things like for example reading or writing numeric values to "registers", by sending formatted messages to the instrument across the serial line, across ethernet, or anything else. As such, you have probably to go to the manual of your instrument, and look up which register corresponds to reading V, I, or what else you need. You can't just expect to write the character "1" to the serial port and expect that the instrument responds in no time with a string, as you're doing in your VI. The modbus library referenced above has VIs for accessing registers, the rest of the information (which register, which port, when, what) you have to provide yourself.

To my understanding, String values consist only of the characters of the string, and either getting them as referenced control value or as indicator content, they won't include formatting any better than they would include any other property of the indicator they came from. I think you'll have to pass the coloring information along by some other means, such as index arrays containing the start and end positions of your coloring. Or, augmenting your string with "control characters" acting as escape sequences determining the colors. As such, they will need to be parsed and filtered out down the line.

I think you can (in fact probably you might be better to) skip the AvailSampPerChan, and just read a suitable fixed number of points. The way I understand continuous DAQ works, is that data is acquired into a ringbuffer internal to the DAQ device at it's own pace, and the DAQ driver cares for transferring enough data to the computer memory as long as the ringbuffer is half full/ there is enough data/ etc. Asking the DAQ to give all its available data just now leads you to interrogate the daq at a rate dictated by the time it took to plot the previous chunk, not at a rate determined by real display need or load balance. I suspect that if you would monitor the number of points which you're getting at each iteration and the time for it, you'd discover that you're ending up still asking too frequently few points at a time, with 100% cpu load. ETA: I missed the Wait 100ms block. However, a fixed number of read points has the same effect, actually better since it is deterministic and dictated by the daq clock, not dependent on whether the GUI thread is delayed by concurrent processes. [Ascertaining, that the time needed for plotting these points is in average shorter than that for acquiring them]

Can your display and your eye keep up with updating 1000 times per second a graph with one point? Wouldn't it be more sensible and less cpu & gpu intensive, not to mention timing exact, to update it 5 times per second with 200 new points? Remember that also Chart History Length gets in the way. Default is 1024 which is much less than 10sec * 1000Hz. Ah now that I think, for a waveform chart you don't even need to bother setting dynamically x axis limits. Update mode Strip chart does it.

Thanks Thomas and Jörg, I agree on both, and partially thought at them myself. Indeed a text file relieves from a changed project vi, and can be inspected without launching the program; and a tag allows complete freedom about version format; perhaps though, tagging should be reserved to "meaningful" versions, i.e. one might want to tag only semistable distributables and not systematically every snapshot, which involves a subjective decision. What I take home from this is - it's not that I haven't yet discovered some advanced option in the project explorer, it's that if I want something specific I have to program it myself with an automated build script.

I devised a lame way, which sort of works with some manual steps, but which I fear is the source of frequent odd compilation errors which I observe; for my current project it holds and I'm not enough motivated to perfection it, but on longer term I think I'll have to. I use git. I still rely on the project build specifications, not on a build script, so I have a build EXE and build installer step which I launch manually, normally just after committing to git. The former has a pre-build script which reads the HEAD identifier and the current date, and saves it as default value to a simple VI providing a string output; that VI is part of the project. One of the main panels of my application gets the version string from the small VI and displays it somewhere. Drawbacks I see are that modifying a VI part of the project as part of the build creates unnecessary source diffs; and that the git SHA is quite criptic to end users as version identifier. I also miss a way to name installers in a way reflecting their version; that I currently do manually renaming the Volume directory, I guess a build VI could take care of that easily too. Pre-Build Action.viGetGitSHA.viVersionString.vi

drjd preceded me, I wanted to point at that too. Despite my asking there, at the end of the story for that case I'm using a generous number of copies of my cluster, like suggested, playing with visibility and position to show only those I need; accessing individual "elements" and manipulating their cosmetics via an array of their references, and opportune property-by-reference accessors.

Seems that repair-install has fixed it, indeed; I'm going now through the cycle of re-upgrading to 2014SP1 after having install-fixed and f1-patched. Code fortunately is all RCS and routinely pingponged across three other platforms, so no tears. But anyhow, turns out that code was ok, local LV not. Same code opened regularly elsewhere. Thanks for the feedback!

Definitely not. I suspect either a former system crash or an antivirus may be involved (this system appears to have a newly installed MacAfee on top of Eset), but can't point my finger yet.

On one system I'm working on, which is not under my sole control, I suddenly noted that the default case of the Event structure is not anymore Timeout, but OpenBinaryLibrary. Moreover, in the Edit Events dialog, I see events for <Application> which I haven't yet seen, and get an error if I try to create a Timeout case with connected timeout terminal. Never ran into such a thing so far. Existing code using the Timeout event fails to compile, (Event data copy, err=1), or loads with messed up event structures (e.g. FitControlToPane instead of ValueChange). This is LV2014SP1. Anyone has any clue about what could have happened? Keywords to search for are perhaps too generic. I have already cleared the compillation cache and rebooted the machine, next to try would be reinstall LV, but I'm wary of starting a long cycle. TIA, Enrico

Relative. A process which is scheduled to last for 0.9862612 sec runs in ~1 sec, not ~0 sec, if it has to be reported with precision of 1 sec.

Yes, of course it can easily be worked around this or that other way, still wondering about the design choice. Even if the mere idea of thinking at a date to fractional seconds precision was a perversion (are we vulcanian?), isn't a bit disturbing that 0.999 %.0t gives 0?

It occurred me to note that, while for instance the number 0.99 formatted (Format to String or Display format in indicator) %#.1f gives 1 , 0.99 formatted %#.1t gives 0.9 and %<%H:%M:%S%1u>t gives 00:00:00.9 . Is there something philosophical about not rounding times, which I'm missing, or is this a bug? I don't think the documentation mentions the issue.

Also http://www.lvs-tools.co.uk/ for me, no pb with other sites. If it's only me, let it be proxy.

I get 403 Forbidden error....

jcesar1029, on 04 Jun 2015 - 7:04 PM, said: Don't waste your time. If, after all, all boils down to a couple of lousy SCPI commands sent serially, that is really the way I'd pursue, and get rid of the Fluke library and all of its use assumptions. From the snippets you show this one doesn't look that terribly written, but from what I have seen with some other 'official' drivers....