ensegre

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.

These days I'm ping-ponging my ongoing project source tree between a development linux system and a test window system, and there is a minor issue which buggers me. The lvproj file is transmutated in a few respects every time it is read by the other platform, and this may generate unnecessary diffs. Usually negligible, as at each commit I typically anyway induce many other changes, though. Looking into, I see: a whole group of items within "Dependencies" is replaced by another one. Where linux has <Item Name="System Exec.vi" Type="VI" URL="/<vilib>/Platform/system.llb/System Exec.vi"/> <Item Name="Get Web Browser Path.vi" Type="VI" URL="/<vilib>/Platform/browser.llb/Get Web Browser Path.vi"/> <Item Name="Get System Web Browser.vi" Type="VI" URL="/<vilib>/Platform/browser.llb/Get System Web Browser.vi"/> <Item Name="Prompt Web Browser Path.vi" Type="VI" URL="/<vilib>/Platform/browser.llb/Prompt Web Browser Path.vi"/> <Item Name="Dflt Data Dir.vi" Type="VI" URL="/<vilib>/Utility/file.llb/Dflt Data Dir.vi"/> <Item Name="Create Directory Recursive.vi" Type="VI" URL="/<vilib>/Utility/libraryn.llb/Create Directory Recursive.vi"/>windows puts a longer block, which includes Registry VIs, ActiveX VIs, BMP VIs and more. I presume that at least some of these deps are due to a little use I make of Report VIs specifically. the entry line for item lvanlys.so is replaced by lines for lvanlys.dll, Advapi32.dll, kernel32.dll the three lines in the Build Specifications block <Property Name="Bld_supportedLanguageCount" Type="Int">1</Property> <Property Name="DestinationCount" Type="Int">2</Property> <Property Name="SourceCount" Type="Int">2</Property>are moved around at different points within the block. Don't know if I'm going to make a big fuss about, just remarking...

no dialogues for me either, the report is on stderr, i.e. I see it on the launching shell. How to escalate it to a CAR then?

So here is another one for me. Attempting to color a strictly typedef'd FP element (which should be just a noop, like wiring a decoration) crashes repeatably LV2012,13 and 14 on two different ubuntu systems I could try on. One-click-crash-loose-all-unsaved-work. Now ubuntu as known is not officially supported so I can't exclude the problem is external to LV (e.g. X), though I suspect a true bug. I followed https://lavag.org/topic/10284-to-report-a-bug-to-national-instruments/ and filed an issue, only to receive after a couple of days the answer from the local AE "no support for linux at our office, please try posting on the general forum". Which I did, and as predictable got quickly submerged by general noise. Is someone perhaps in condition to quickly check the same on a different distribution?

Impressed. I remark that 1 gives only first children, while 2 all descendants. At least with a 3 generation hierarchy of mine which I tested.

Picking the desired element of that static array. I guess I need to educate myself more about the factory pattern in future. Thx for the answer!

Precisely what I did. Not even an ID method, just Get LV Class Name.vi for now, but that's the idea. I thought there must have been a smarter way, like this I would have to maintain the static array every time I create a new class. [Ok, the question was purely academic: I have so far just three such classes and they are not supposed to increase any soon. Even.] In what sense managing?

It may well be. Suppose I have a class Devices to which I add incrementally (coding more, plugins are yet over my head) children drivers for specific instruments. I want to display a list of those implemented so far / offer the user to choose which instrument to use for a task among those available, and such.