ensegre

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....

oh, I was just saying. Maybe the subVI is part of a library you don't want or you're not authorized to change. If it is yours, you can. so is the instrument really reading for 15 minutes? integrating the thermocouple voltage? Does it need a labview program locked on its shoulder just to integrate with time constant tau? If the goal is to talk once in 15 min with the instrument to get its last readout, let the main do that, say with an event structure that fires the read in the timeout case, which times out every 15min, but quits the while loop if the stop button is pressed, as was suggested above. Why do you need to lock a subVI waiting, and then pretend that its caller can abort it?

If you are allowed to change the code of the subVI, you have options. The quickest and dirtiest would be to insert a global Stop variable, set to true by the gui, and to have the subVI poll it. More elaborate options including establishing other communication channels, like a message queue, between main and subVI, or options of calling the subVI dynamically and aborting it by reference come to mind. But basically, all boils down to give the subVI a chance of exiting before the full interval of 15min has passed. What nature is the 15min scan of, can it be split into shorter scans? What is the hardware doing at all during the 15min, and can it be aborted? If the goal was be just to take one datapoint every 15min, and communication with the instrument itself would take no time, the periodicity should by all means be handled in the main and not as a timeout.

Without entering into your code, which maybe only suffers from a bug in AVI1.llb (which I never recall to have needed, my customers who shoot at such speeds as to produce TB of videos can't write it as avi in the first place), usually I use a different logical structure, with: ringbuffer, producer-consumer loop, and IMAQdx grabbing driven by the FrameDone dynamical event. The latter I would never have discovered myself, I just found it on the IMAQdx example wich used to come with Labview, and upon which I have since them based an uncountable number of grab-from-usb/firewire/gige camera snippets plus trigger/logging/lighting/messaging/whatever which I've been asked. See if the attached sample is of any help to you. Not much of a state machine, but should cover your functionality. I'm not on windows now, so I hope I'm passing you a functioning version of it. HaveYouEverSeen.vi

Additionally, there seems to be a certain TeliCamSDK, maybe she was referring to that.

I've used in the past USB analog frame grabbers like this. They are particularly convenient because they are generally recognized as IMAQdx, indeed. However, the OP wrote "I installed the camera", and "The camera maker has provided some dlls", so either a framegrabber was already bundled there, or she is talking of some other digital camera. Toshiba Teli has many product lines, including GigE, USB3, Firewire, CameraLink, CoaxPress, not merely analogic. If by chance we were talking of a GigE camera, all those I have seen in the last years were Genicam compliant and supported by IMAQdx, which is imho by far preferrable within labview to wrapping a dll. I presume this is not the case, as the OP wrote in contrast "but it is not listed under MAX devices". Which in turn assumes that she has installed IMAQdx.

just to exclude the obvious, are you perhaps using an absolute path to it in a CLFN? http://zone.ni.com/reference/en-XX/help/371361L-01/lvexcodeconcepts/locations_for_shared_libraries/

with highest probability: you're somehow passing wrongly sized data to your function. Very common mistake to go through. the linker cannot write a new dll, because LV is still locking the file. IIRC it is sufficient to close all VIs containing CLN to the dll to release it.

Back when I was doing my master thesis, we had a mainframe connected with a bunch of serial cables to a number of DEC VT220? (vt100 on steroids), a couple of VT240? (ditto plus tektronix 4015/6? emulation) and a couple of Mac SE/classic/II with a serial terminal emulator whose name I forgot, around the offices. Working involved programming in fortran, compile on VMS crosslinking with an NCARplot library, run the executable which generated a graphics metafile, launch a certain metafile viewer, switch manually the VT240 to tektronix mode, and see the graphics build up vector by vector as the data was sent in on the serial line. I don't even remember which monitor had color at all, probably only the boss' MacII+. IIRC, the mac emulator was even a bit more sophisticated because it could swap vt100/tek mode by means of some escape sequence, imagine the results of noise on the serial line. So yes, by means of VISA writes Labview may cause a tektronix terminal to display some nice graphics, but is that what is asked? http://vt100.net/tektronix/4014-um/4014-um.pdf for instance contains reference to the graphic commands. As per wikipedia, xterm -t still supports tek emulation.

In the Build Specifications/Source File settings, I see all options of passwording, removing FP and BD for individual files and groups of them, even for Source Distribution builds. Never occurred me to try it out, but isn't it enough?

How sophisticate are the .m constructs in the output file? If they are basic, like variable assignments, and if the are consistently patterned, perhaps an ad hoc text scan can do. And if they are just a bit more complex, e.g. they involve some arithmetical and mathematical functions, they may be passed with minimal transmutations to formula nodes. Formula nodes are in my experience somewhat slow, but if manual exporting steps are involved, the parsing delay may be negligible..

CAR 526281

Did so. Thanks for confirming.