Donald

I do not think anything changed in 8.5... This info is available in knwoledge base of NI. I guess the problem is the logos protocol which is only available for Windows...

Shared variable support for LabVIEW 8.2 for Mac OS X or Linux is limited to using single process shared variable nodes that were created and configured in LabVIEW 8.2 for Windows. Projects and VIs that include shared variables will open in LabVIEW 8.2 for Mac OS X or Linux but they cannot be reconfigured.

Network shared variables are not supported in LabVIEW 8.2 for Mac OS X or Linux. In addition, the PSP protocol that can be used to connect to shared variables from LabVIEW for Windows via datasocket is not supported. See the Readme Files for LabVIEW 8.2 for Mac OS X and Linux linked below for more detailed information about shared variable support on these platforms.

QUOTE(sVeNvAeTh @ Sep 24 2007, 10:54 AM)

I have to convert a string in a DBL. That is no problem, but the string uses decimal power,

like 1.54 E+02.

Now, I get the right value, but it only shows 1.54 and not the decimal power.

What is the mistake?

The white space before the exponent is the problem... LabVIEW needs 1.54E+02. There are numerous ways of solving this. You could for example use "search and replace string " and replace '/sE+' by 'E+'.

QUOTE(rolfk @ Sep 12 2007, 08:12 AM)

My best bet is .Net although I think the WinAPI will also give you this information on a somewhat lower level and probably not exactly trivial to access. Possibly LabVIEW has some private hooks itself. Would make sense to have this info in LabVIEW somehow to make it platform independant.

Rolf Kalbermatter

There is a LabVIEW example "SimpleTaskMonitor" that uses the .NET interface to get information from the performance counters in the system assembly.

QUOTE(crelf @ Sep 6 2007, 04:46 AM)

That's a good one - can you please add it to http://wiki.lavag.org/LabVIEW_configuration_file.Execution_System' target="_blank">this LabVIEWwiki page?

Ok, done.

Don't forget to put following key in .ini file: runAsService=TRUE

This key tells the LabVIEW Run-Time Engine to ignore the Windows WM_ENDSESSION message that is sent when a user logs off!

Hello,

I've read some articles on the net where the FFTs are calculated on a ATI Graphical Processor(s). The performance seems to be incredible. I'm running on NVIDIA so I didn't test it...

Here is a link that gives an idea what is possible : HW Image Processing

I guess you have to develop C-code to use this in LabVIEW and I have no idea if it is faster than the NI FFTs algorithms (which are very efficient).

Best Regards,

Donald

Hello,

The DLL is causing the problem by blocking the user interface thread. If the DLL is threadsafe you can run it in another loop (subvi) which is configured to run in another thread e.g. I/O.

Is the DLL threadsafe???.... if LabVIEW crashes it isn't :-) If it doesn't crash, you're still not 100% sure...try asking the supplier of the DLL..

A possible solution is to build 2 apps. One GUI and one data capture process. Communicate by Data Sockets, Inter process shared mem (cfr pipes) or tcp/ip sockets. (NOT queues).

Good luck,

Donald

How do you connect to the device? Do you use a DLL or the USB communication functions of LabVIEW?

I suggest you add a screenshot of your code.

Did you try to change the read-only properties of all source files to r/w? The error indication could be caused by a File Open function with access rights read/write. Source Code Control often sets all source code files read-only until you check them out.

Hello Ad,

For me following approach works (on a fast PC).

Load the main VI or a Vi Tree that contains your application's modules.

If this fails (labview crashing during loading of VIs) -> try a mass compile of source code directory, and reload again

Force a recompile all. (Shift + run arrow) BEFORE edittting the type defs.

After the recompilation of everything, depending of your problem- it is possible to edit without crashing.

Save all VIs or better (or if you use SCC) save all the VIs you've been editting.

Good luck,

Donald

I would like to use Vista Pro at home to be prepared when customers start to switch or are forced to switch because of an obsolete notice for WinXP... I got a confirmation from an embedded PC supplier that OEM WinXP Pro will be available at least until end 2008. The hardened security is also more than welcome but yes I expect similar problems as on Win XP if your are not administrator (user can not scan or print...was a famous one for one of the biggest InktJet Scanner suppliers).

An interesting feature (yes you have to look hard for an extra pro feature...) in Win Vista Pro I would like to test is the "Shadow Copy" feature. I've not seen much about this feature in Windows Vista reviews.

This feature promises to save different version of a file. This sounds good if you do not use Source Code control and have the bad luck of corrupting a VI or worse a complete LLB.

I also expect a lot of problems to install/use existing applications if the active user is NOT an administrator. Another reason to start preparing. (and keeping Windows XP just in case)

If the RT OS is a win32 compatible one, you can probably use a win32 function call.

The attached VI is an example of a possible solution. There are various similar VIs available on the net.

I there is a cmd interface available on this RT system you can also the System Exec.vi to start a batch-script (the command string will be "cmd.exe /c shutdown -s - t 0" or something similar depending on your needs)

Download File:post-2015-1169810418.vi

I got a LabVIEW (commercial!!!) application with a scary diagram that doesn't even fit on this screen, I wonder what the developer used... Google maps maybe

You did not provide a screenshot of your code or any VIs so I have to guess what's going wrong.

It guess you should use the lower level DaqMx VIs instead of one VI that starts the daq tasks and fetches 15 seconds of data.

Did you have a look at the LabVIEW daqmx analog input examples, there must be an example that gives you a hint how to handle this task?

Hello Constant folding bug hunters,

There is a old post that turning of the options of constant folding doesn't solve the problem... At the company I work for (CIT Engineering) we are preparing an introduction for all our developers/students to move to 8.20 I would like to hear what is best to do before there is a bugfix (8.2.1/8.3). Should we turn the options of or not. I'm a bit lost here.

FYI: Speed/memory optimisation is not an issue on the king of all desktop processors a CoreDuo intel processor... they know how to design a processor in Israel... impressive to see LV8.20 start in less than a second. Ok embedded targets are probably better of with the optimisations but only 10% of our projects run on such a platform and the application size if limited.

Donald

It seems not to be possible for a non-premium member to edit this knowledge base article... so I just created this post instead.

NI please could you not improve the procedure of reporting bugs? I'm sure there is many stressed developers who will not report a bug if they have to start calling NI to report a bug.

I have noticed a lot of developers - even experts that have used labview since 1.0 - not reporting a bug just because they think it cost them to much time and there will not be a (free) service pack anyway. I also commited this sin...and know how frustrating it must be for the NI Core LV developers not to be aware of a bug that caused a lot of headache but could have been reported.

The success of the LAVA buglist seems to be a hint that there is missing something in the whole process of reporting bugs. The bug list on the NI forum is not complete at all and even difficult to find if you are not a forum expert.

A suggestion I have:

Please have a look at Solobug which is a small application included with TestTrack issue tracker from Seapine.

I'm sure something similar is possible with LabVIEW.

Carefull bugtracking by the LV users is what NI needs, not making phone companies rich, often developers in Europe work over the borders and phone calls are time consuming and very expensive in Europe. As I live in a country where there are 3 official languages a phone call isn't always the most 'bugfree' conversation.

Phone support with NI Belgium however is most often excellent and should be used for urgent problems or discussing dramatic price reductions not to discuss a minor bug :-)

As an alliance member I've only seen offical direct mail by NI about flaws in hardware, why nothing about software. Microsoft also gives detailed information about bugs that affect most users.

It is a pleasure to see the commitment of some NI developers on this forum to follow up bug reports. Please NI, support them with good bug tracking procedures!

Hello Bjarne,

Accessing an OPC server on a remote computer requires configuration of the DCOM interface and this is - at least for me- not an easy task. There is a configuration white paper available on the OPC foundation home page. I remember that even this detailed white paper is not complete when the OPC server computer is not included in a Windows domain. The problem gets worse when the active user isn't an administrator. OPC is nice but very complex for a technology that is used by many developers who do not have the time to configure firewalls and access rights :-0

I didn't think it was possible to run an OPC server on a realtime OS like VxWorks. I'm not sure if this will solve your problem as I don't understand the problem you are describing. I only have tried it on Windows only platforms and without reconfiguring various DCOM objects and access rights it was impossible to use or browse any OPC tags on a remote computer. I've even had an OPC server that I could never access over the network, using it on the same computer was the only solution. A solution could be to create an extra LabVIEW process on the remote computer that uses the LabVIEW data sockets or a custom made TCP or UDP server solution. This was a workaround for a Linux LabVIEW solution I had in mind for a die hard unix customer.

I would say good luck. I hope you let us know if the solution of Tom L. works for you!

Venlig hilsen

Donald

I've used Bugzilla and "Test Track" from Seapine but without source code control integration. They both worked very well. The interface of the version (3 years go) of Bugzilla I used was overwhelming and there was a (expensive) DBA behind it... It was a Solaris/Linux only environment. The searching-configuration feautures where extremely powerfull. Report functions very limited. Maybe this improved in the newest release.

Test Track is more polished and seems to be better for Windows developers (Visual Studio integration), it has everything you ask even more I guess. The price was no issue compared to the hardware costs of the project. Seapine software quality is very high I have never seen a bug in the bugtracker :-)

I would like to test Microsoft Team Server but the license price is very high. I don't think there is subversion support in Team Server.

Best regards,

Donald

50x faster? I didn't know the improvement was that dramatic. I have an speed issue in a LV7.1 application with the OpenG /NLConfig Variant config VIs when loading a very big settings file, it seems I have to force the customer (Johnson & Johnson) to go for 8.20.

It seems somebody at NI deserves a Belgian beer :-) or chocolate bar. Who?

This looks like a very good idea to extend the power of one of my favourite features of LabVIEW 7 (or was it 6.1)!

I wonder if the LabVIEW real time compiler can handle such a wire. I guess it is not an easy job, else the untyped wire would have been there already. I can imagine that an untyped wire also has less overhead than subVIs.

I agree that a polymorph VI based solution is not so easy to master when you start editting the existing code. It is very easy to introduce a bug or if there are a lot of functions it can be quite a job to start editting all these VIs manually since a "replace all" action is not available yet (a source control tool is a big help here). I have not enough experience with other languages on this level to compare.

I guess you do not want to use variant type based solutions because of the speed/memory penalty?

FYI: I don't know if you are aware that editting polymorph Vis is only possible in the professional edition of LabVIEW.

Hello,

I think you should consider a redesign of your code starting from one of the Design Patterns included with the standard templates. Depending on your knowledge of LabVIEW and application requirements you should go for a one loop state machine or consumer/producer pattern with 2 loops.

Also consider using events instead of polling buttons and do not forget your error handling.

Best regard,

Donald

What is your LabVIEW version? I have the impression that you added a NON-VI file as a dynamic vi.

Joris,

For me it was a bug because the behavior of enabling the 'LV7 format' mode or not didn't seem consistent.

Because the content of the string should not be used without using the type descriptor my first thought was: it is not a bug because one should always wire the type descriptor output. However I can think of constructions where there is no need in wiring the type descriptor everywhere in the application I just looked around in an existing application I'm working on here in Beerse and yes I identified a construction where it will go wrong when converted to LV8.2.

I will send the problem as 'odd' behavior to NI support.

Best regards,

Donald

Hello JFM,

Thanks for the fast reply. You are right I just tested it, the connection of type descriptor solves the problem. Didn't notice this difference.

Note: The flattened string content is (as expected) not the same when set to 'lv7 format', I know that I should not parse this content myself but rather use the unflatten function :-)

Mystery solved and NOT a bug.

Best Regards,

Donald

Hello,

I would like to hear your opinion whether the problem demonstrated in the attached VI should be reported as a bug.

I found this problem when I was developing a GPIB(VISA) driver for an old HP Pulse Counter. I've often seen a + sign in front of numerical strings when using SCPI based instrument interface so I guess this info could be usefull for other developers.

Why using a unsigned data type someone might ask, well the instrument was a counter so I needed a U32 data range.

Best Regards,

Donald

Download File:post-2015-1168603443.vi