mprim

Norm,

Have you created any commands yet in this new architecture? I would like to transfer the old ones, from the previous LV Speak, that I have to the new architecture.

Thanks,

Mark

SQLite Error

SQLite error check.vi

Sam,

Would you be willing to share some vi's or more information about your experience in using the DLL-import feature? I have had a lot of trouble using DLL's with LabView.

Mark

I have used Sqlite since 2004, my first implementation I used a wrapper dll around the Sqlite3.dll. But now you can use the DLL-Import feature of LabVIEW and import the Sqlite3.dll and have yourself a fully working toolkit. After import you have to replace a couple of Type-controls to Int32 and you will be done in less than an hour.

I don't want to be mean but what are the difference between your toolkit and what Dll-Import makes. I can appreciate a Toolkit that simplifies working with LabVIEW data and Database so that the programmer does not have to use a single SQL statement.

Norm,

I noticed in the AMC documentation that it is suitable for use in machine to machine communications over TCP/IP networks. Is LVx implementation superior to the AMC implementation?

Mark

The AMC is on NI's website and was developed by another Systems Engineer Christian Loew.

Documentation on it is listed there.

The TLB's documentation is ..... in work although the presentation is a good starting point.

Most parts other than the dynamic event registration are straighforward, but the rules of thumb and guidelines need to be well noted somewhere.

Norm,

I can definitely wait a bit. I have the previous versions on my machine and have been playing with them. In the meantime is there any good documentation on TLB and the AMC class that it uses extensively?

Thanks,

Mark

Mark,

Thank you for bringing this up. You are correct in your observation that the two technologies (LVx and the TLB) work together and work together well.

However one is not reliant upon the other, just as the JKI exports were not critical to the overall JKI SM.

LVx is the technology that enables the interprocess communication and has been in a state of preparation for mass distribution for a while and that statement still holds.

Currently the process of making a new command is too cumbersome and desperately needs tools to aid in the process of creation of new commands.

That and some good documentation (although the code is very clean)

So if you use the TLB, because of the structure, adding LVx (LabVIEW Exports) to your baseline implemented code should be simple.

I am very tempted to post the current version out here, but then the process installing a package once I finish it will cause conflicts, so I hesitate for a minute.

Will you be able to wait a little bit till I package it up in a VIP?

Norm,

It was mentioned in the NI Week 2010 State Machine vs State Machine powerpoint that the TLB State Machine "Can communicate to anything made in LV anywhere in the world." How do I go about making two TLB state machines communicate with each other?

Also this work appears to be a derivative of your previous LVx work. Also previously packaged as RFSE Tools. Do the examples created for LVx apply in the TLB state machine?

Thanks,

Mark

Norm,

Here is an updated class template that includes my suggestions for how to handle the various Gobj clasees. I have also attached an update engine and startup vi's that run hidden and close automatically when "Speak Stop" is given. I have updated the property class and part of the text class plugins as well. They are attached. There are a couple of other updated/new vi's as well attached.

Regards,

Mark

Speak Update.zip

Very quickly though, please find the .NET components that utilize the speech to text as the activeX component does not work on my system

Norm,

The Text to Speech vi is off of the NI website at http://decibel.ni.com/content/docs/DOC-2263 it uses the same Microsoft SDK.

Mark

Norm,

I really like the second version of LV Speak. Attached is an edited copy of the project. I added several features:

1. The QuickEdit and LVSpeak engine vi's are no longer visible, they are minimized at launch. The functionality of these vi's front panels has been built into the program.

a. To list the commands LVSpeak recognizes say "list commands" and a listbox of all available LV Speak commands appears.

b. To reload the plugins say "reload"

c. To stop say "speak stop"

2. There is also now audible feedback for every command as well as the reload plugins command. Every command is echoed back to the user, the reload plugins command provides audible feedback when it finishes.

3. I also changed the Locate QEC Plugins vi so that it parses the commands in the QuickEdit Command.lvclass

4. I added a new class for property nodes and three new commands: Property Value, Property Read, Property Write.

I have several suggestions:

1. Change the format of the QEC class Execute VI such that the FP / BD case structure is inside the command name case structure. This allows for commands that are not specific to the FP or BD to be only coded once. Also it makes it easier to track whether all possible cases for a given command have been coded.

2. Filter the available command grammar such that only the ones valid for the currently selected objects are available. This would reduce the number of errors from the speech engine.

3. Add audible confirmation to the delete command.

4. Provide right click functionality such that the user could either speak the command or click it with the mouse.

Thanks again for all of your hard work. I am trully addicted to LVSpeak. Attached is a zip of the .lvproj file. If there is a better way to send you this please let me know.

Mark

LV Speak.zip

Norm,

I have done a considerable amount of editing to your original LVSpeak release that has made it more stable. I have also added a few commands. Attached is a llb that includes the edited engine.

Mark

Ok all you willing furry animals.

Attached to this you will find the new architecture.

I do not have a quick drop package just yet, but give me a day.

But for now I need to validate that this install goes smoothly and still is functional on all of you're PCs

The interface is still the nasty 2 floating windows and I'm up for recommendations on how you all think this would best be shown (1 detected speech window, for LVS core or QE, no window, how big, where to put, what options on the window and on and on.

It should install to 2 primary locations

LVS core goes in <project> (and there is a .lvproj in there as well to see how things are setup)

Quick Edit and it's plug-ins go into <resource> (videos and documentation for creating new QE plugins are on the way)

and just to make things difficult on you guys for the moment, you need to install RFSE Tools to your user.lib directory (still working on the best method of combining these into 1 install process)

So as it stands, uninstall all LVS packages, install this new one, and also extrace RFSE Tools to your user.lib directory.

Not all of the old QE commands are fully implemented yet, but there is a VI in the QE directory that shows the list of currently installed commands.

More refinement on the way soon!!

and please let me know asap of any install or getting started issues

LV Speak Edited.llb

QUOTE (gmart @ Oct 16 2008, 05:04 PM)

Do you have the service request number? I am not aware of build times slowing down by 2x between versions. In your particular situation, do you have build times for both 8.5 and 8.6?

My service request number is 7212358. NI tech support confirmed that this was a know issue.

bluesky

QUOTE (Norm Kirchner @ Sep 8 2008, 08:39 AM)

Ok, something is fishy here.

I've got a program that is not complex by any stretch of the imagination.

I've got some LVOOP stuff in there but very simple structure 1 class owns 2 other classes, no inheritance.

and the LVx package that does have inheritance, but has been built in 8.2 before w/out issue

And as I try to build it into an EXE, going on minute #5 now, I am still waiting for the build to initialize... WTF!!!!

Never have I seen it need to sit so long for an init of a build, but it will finish eventually... like the moment I walk away because I'm tired of trying to see how long it takes and give up.

So the question is, has anyone had a simple program cause the EXE builder to take FOREVER on the init of the build?

Going to start an NI SR as well but wanted to see what others have seen.

Norm,

I started a Service Request for the same issue. According to NI this is a known bug with Labview 8.6 Build times have more than doubled between Labview 8.5.1 and Labview 8.6

bluesky

There has been some discussion of how to best prevent reverse engineering of Labview .exe files by obfuscating the vi name etc. What about simply obfuscating the exe by using one of the many available programs. I ran across this one that sounded interesting:

Bitsum's PECompact2

bluesky

John,

Are you running this as an application or in the development environment? Also has the hardware you are running it on changed? Did you upgrade OS's. Have you tried running a memory check on the machine your are using? Have you tried checking the CPU usage on the machine? ie are you running out of CPU cycles? Also try using Wireshark on the TCP/IP port to check for strange traffic.

It just seems strange that Labview throws this error only occasionally. I use a number of queues and parallel processing some of them with high speed data with very few problems especially on Labview 8.5.1

Have you tried mass compiling your entire project. I have found on several occasions that Labview seems to have trouble keeping track of changes to queues. The problems disapear when I mass compile.

Mark

QUOTE (jlokanis @ Sep 23 2008, 10:57 AM)

Thanks for the observations. In the case of this VI, the upper loop, or 'producer' is trying to read all the data from a TCP connection (in this case a remote serial port broadcasing at 19200bps). The lower loop (consumer) is processing the data, looking for a certain string. I want to ensure that no data is missed so the top loop has to run as fast as possible to avoid a buffer overrun. It reads data in large chucks but uses immediate mode with a timeout of 10ms. So, every 10 ms it reads all the data in the buffer and passes it to the lower loop. I have been using this code for a very long time (5+ years) without having a memory overrun issue.

The problem I am having now is something is killing the queue reference outside of this VI. Since the queue is unnamed, it is supported to be technically impossible for the refernce to go invalid while the VI is running and the release queue has not been called.

Also, this is not the only reference that does invalid. I have error logging throughout my code that shows multiple references going invalid at the same time in unrelated VIs (all of these use 'private' unnamed queues). What appears to be happening is when some reentrant or VIT spawned code leaves memeory, it accidentally kills other queues in other instances of the same VIs. Or, something is corrupting LabVIEW's memory.

NI App support is trying to reproduce the issue. I will let you all know what they tell me in the end.

-John

I had a major problem upgrading from Labview 8.5.1 to Labview 8.6 My problem was with the DAQmx drivers. I worked at length with NI tech support to fix the problem. Service Request Number 7206333

I learned the following:

1. When upgrading do not download and install just the Labview executable without the supporting drivers. Make sure when you upgrade between versions that you install from the distribution DVD's that include all of the supporting drivers. The problem started when I downloaded just the Labview 8.6 installer.

2. When I installed Labview 8.6 from just the downloaded executable instead of the distribution DVD's it did not license properly.

To fix the problems:

1. Uninstall Labview 8.6

2. Install Labview 8.6 from the Distribution DVD's and install the 8.6 compatible drivers needed for the hardware you use.

This fixed my problems with DAQmx and the licensing problems were corrected as well.

In my opinion NI created this problem by releasing the Labview 8.6 executable for download before they released all of the necessary drivers.

bluesky

QUOTE (Neville D @ Sep 23 2008, 09:31 AM)

A quick recap of your experience here would be helpful to all, I imagine.

N.

Your vi makes a number of assumptions. It assumes that the second while loop can process the data in the time it takes the first while loop to acquire it. If it does not the number of elements in the queue will grow very quickly. Are you sure your second while loop can process the data as fast as it is acquired? Are you sure your CPU is fast enough to acquire and process the data simultaneously. Also what thread are you running this vi in?

Naming the queue is a good idea. Also try declaring the size of the queue and check the queue to see if it is full before you enqueue another element. My guess is that Labview is not dequeing the elements fast enough. I have had similar problems and was able to track the problem by monitoring the queue status while the vi is running. Use the get queue status vi to monitor the queue.

If you don't declare the size of the queue Labview has to constantly allocate more memory for the newly acquired data.

bluesky

QUOTE (jlokanis @ Sep 19 2008, 10:18 AM)

I took this one step further and changed all my unnamed queues (except this one) to be named using a GUID (from a .NET call).

So far, this has not helped (other refnums are going 'invaild' at the same time as this one). I think there is a bug in the code that manages references where clones leaving memory can somehow kill the references in other clones of the same VI.

I have NI support digging into this now. I hope they can offer me a work-around.

When looking for information on how to do something new try Googling your question first. Googling "Windows Shutdown" I quickly found: http://www.aumha.org/win5/a/shutcut.php

The best place to look for information on native Windows commands is on the Microsoft Developer Site.

Bluesky

QUOTE (DidikChandra @ Sep 13 2008, 03:53 PM)

Hello everyone,

I'm trying to figure out how to disable all PC ports that maybe used to leak information from the PC. I'm using a PC to create a HMI that connects to a PLC. My LabVIEW program directly starts when windows is starting up. I'm not using any keyboard or mouse, instead I'm using a modified 19" LCD screen to a touch screen panel. So any unused ports I should disable or maybe block certain feature connected to it (like for USB I should block feature for Flash Drive, USB Hub, Keyboard, Mouse but allowing only the Touch Panel Interface). I've found some third party utility for it, but I'd prefer to have LabVIEW to be in control of everything.

Second, since the PC is not allowed to be used for anyother purpose, then shuting down the PC should also be from LabVIEW ... Now I'm completely blind on how to do that , please shine some light on me.

Best regards,

Didik Chandra

I prefer Process Lasso for monitoring as well as controlling applications.

You can get it at:

http://www.bitsum.com/prolasso.php

Looking for a way to get the rights of the current logged in Windows user. With all of the new restrictions placed by Vista I need to know whether or not the current user has "Administrator" rights. I found on the MSDN site the LsaOpenPolicy function by I am not familiar with Windows programming. Has anybody else tried to tackle this?

Bluesky