dhuff

first of all, what data do you mean, is the ID looking strange? What type of CAN and what baud rate are you using? There are a few examples on the NI.com webpage that might help. Check there for starters. NI CAN help

1. Open NI Measurement & Automation Explorer (MAX) 2. Create some Fieldpoint items 3. Save Fieldpoint Configuration File (.iak) with a non 8.3 filename, for example "my configuration to save.iak" 4. Close NI-Max 5. From Windows, double click above named .iak file to work with it. 6. Note that the file name is listed as "my~1.iak" indicating MAX CAN NOT HANDLE THE NON 8.3 FILE NAME. If you try to do a save, it also seems to not work right, meaning any changes will not be saved. 7. Press F5(refresh) and note that does not fix the problem. If you open MAX and right click and use the Open menu item the system will open the file correctly, and show the full file name. This same behavior also shows up if you have MAX open and running, and double click on your .iak file as well. It looks like something is not passing correctly when opened by Windows. Details: WinXP 32 bit, SP2, Labview 8.0, Fieldpoint 5.0.0116, NI-Max 4.0.0.3010

I agree with everything stated so far, but would add 2 simple things 1. I use the Process Explorer <Process Explorer>From Sysinternals.com This FREE utility will allow you to see what is running in the background, and optionally disable it. There is also another FREE utility at the sysinternals site called AutoLogons which will allow you to easily browse and diable stuff that starts when Windows boots (it is easier than browsing the registry). 2. Video Acceleration This has been an issue with Labview in the past, if the video acceleration is too high it will cause glitches trying to resync what is displayed on the front panel. This problem seems to show up especially in Laptops. Click on Display>>Settings>>Advanced, then check the tabs for a acceleration or Troubleshooting Tab.

I am assuming you mean the .dbc file assocated with CAN traffic. This is the Vector CAN message traffic database file. It defines the CAN message identifiers, repition rates, and data variables. If you go to the Vector website you can learn more. <www.vector-informatik.de>

OK, a few quick things, The CAN interface for the CAN Init Start.vi (the middle VI) shows that the channel might not be setup correctly in your interface. You usually tell the task to send on channels like CAN0 or CAN1. Those channels are defined in NI MAX (Measurement & Automation Explorer) So you need to start NI Max, and define the CAN channels. This tells Labview which physical CAN port is CAN0, and details associated with it. Second Thing: CAN communications require at least 1 listener and 1 CAN sender, otherwise the CAN interface will report a CAN bus error. So you need to start the receiver before you send. You also need to make sure you are sending and receiving the messages with the same baud rate, and the same length of CAN ID (11 bit standard ID or 29 bit Extended ID) Third Thing: You should really connect and use the error input /output clusters, they will usually help tell you if the CAN interface has a problem. Your VI does not have the error clusters hooked up to help you. (If you run it in Execution Highlight Mode they will show which VI has an error) There should be some examples installed when you installed NI-CAN which might help. Since you are using Labview 7.1, start labview, click Help, Then Click on Find Examples. Under The Hardware Input And Output Folder, You will find a CAN folder. Most of those examples are also on the NI website, Look for them under industrial networks NI Developer Zone > Development Library > Industrial Networks > CAN Hope this helps

As far as recompiling everything, Labview only includes the ability to recompile VI's back 1 version. So if You want to convert a VI from version 7.1 to version 6.1, you need to follow the steps below. open the VI in Labview 7.1, and save for previous version 7.0 open the VI in Labview 7.0, and save for previous version 6.1 As for compatibility between versions, labview 6.1 will not open a VI written in 7.1. You have a few options here. 1. Write everything in 1 version of Labview 2. Write ALL you VI's in the earlier version of Labview, and treat them as read only. You can then call them in both versions of Labview, the read only part will keep the system from recompiling them to a newer version. 3. Fork your VI's, make 2 versions, one for the old, and one version in the latest version. You may be forced to do this, especially if you have VI's that use new features. Hope this Helps.

I will also say I have heard good things about beyond compare, but never used it myself. I have used a homebrew method, using MD5 checksums. I use MD5summer (free download at http://md5summer.org) to create a MD5 fingerprint of each file and store it in a data file, then I call routine in Labview to calc the MD5 of a file. If it does not match the one stored in the data file, I have a problem. I like MD5 because it is better defined than a 32bit CRC, and the MD5summer can read and write in a format understood in Windows or Linux. I also second the idea of using some source code control. Many times, you want to know if something has changed, and more importantly, WHAT has changed. That is where the Difference tool built into Labview can help. Jim Kring made a Diff Tool add-on (http://meta-diff.sourceforge.net/lvdiff.html) to Tortise CVS (http://www.tortoisecvs.org/) so that if there is a change, it can open the VI's to show you the 2 different ones side by side. I think there is also a way that this can be done using MS Visual Source Safe add-in for Labview.

OK, before we get into flame wars, my suggestion was to use an easy DOS command, basically it is no extra software to build or buy, so everybody relax, I was trying to get a simple point across. Some important questions: Why do you want to know the contents of the window DURING RUNTIME? Is there something there in the DOS window that will not be there when it finishes? Does this DOS sequence involve many steps or commands? Does it involve keypresses or user input decisions too complex for the computer? Is this on a remote platform or other special platform that does not facillitate easy use? Is this DOS process long enough that you can not wait for the result to finish? My central point is: Most of the time, DOS or system exec commands are "one time events" meaning once you invoke the command, it will execute in a seperate process until it pauses, crashes, finishes, or exits. THERE IS VERY LITTLE YOU CAN DO TO STOP DOS ONCE IT STARTS, so the question is why would you want to stop it or change it? You launch DOS to execute a DOS command, the computer thinks, and then shows a result. The DOS System Exec is really a seperate process, it was designed that way on purpose. If you use a output pipe command, it will give you a complete record of what happened after the fact, but it can't change what runs in the command line. If the commands you run take a long time or need to have user inputs or displays, look at using the application focus part of Labview, you can make the DOS window be on top of the Labview window, or the other way around.

does your dos command finish quick? I have used the DOS output redirect command to pass results to somewhere I can find. Then you just read the results back into labview. For example, the command below will "redirect" the output of the dir command into a file called output.txt: C:\dir *.* > C:\output.txt I have used this for a quick and easy way to read the results of DOS commands issued in Labview back into Labview.

and for you firefox fans, http://www.funnyfox.org

have you looked at the System Exec.vi (located on the Communications Pallette)?

First, you must have the Labview Application Builder installed, it is an additional package for the Labview development system, it comes with with the more expensive versions of Labview. (Labview Full Development Version, or Professional Development Version) If it is installed, open Labview, and click Tools >> Build Application or Shared DLL. A window should pop up, allowing you to specify files to include and such. The main thing to remember is to click on the pull down menu for build type, and choose Application (.exe) There should be more info on the NI website, search there for more details.

I found a strange bug where saving or updating custom Type Defs will not change their revision numbers, and I was wondering if anybody else has seen it as well. It appears that the revision history does not update when you modify them, and it does NOT prompt the user for description when one is changed. So if one of the people working on a HUGE vi project changes your defined Type Def, ALL vi's will see something has changed in the type def, but you are probably out of luck figuring out what changed in the type def. Here is the sequence to follow to find it 1. Go into the Labview Revision control options menu (Tools>>Options>>Revision History 2. Set the following options True (checked), Add Entry Each time VI is Saved, Prompt for a Comment When VI is Saved, Show Revision Number in Titlebar 3. Restart Labview so the options above take effect 4. Make a new VI, then place a new Enum on the front panel 5. Right Click on it, and Click Advanced >> Customize 6. Edit the items in the Enum, add 1 or 2 options 7. Change the pull down menu to Strict Type Def, and save it 8. Close Labview, then double click on your new type def control to open it again 9. Edit the items in the Enum, and resave it. Notice that THE REVISION NUMBER DID NOT change 10 Repeat steps 8 & 9 as many times as you want, the revision will NOT change, and you will not get the Revision History nag screen to enter comments I tried with Enums, Text Rings, and Menu Rings, they all show the same problem. You can also use both Strict Type Defs, and regular Type Defs, the result is the same. This was done using Labview 7.1.1 on WinXP.

I have a Garmin GPS18, and I found that the GPS will output data format is changeable, it will output data in Garmin Format, or NMEA, but not both at the same time. Mine came from the factory sending data in the Garmin format instead of the NMEA format that I needed, so I had to change it using the software tool on the Garmin website. (go to <http://www.garmin.com/products/gps18oem/> and click on Downloads, and click on the Unit Software) Second thing, is that your computer will make a "virtual serial port" after you install the drivers for the USB converter. You can use NI Measurement & Automation Explorer (NI-MAX) to check what serial ports are accessable in LabVIEW. You usually need to have the computer started with the USB converter in and working before Labview can access it. Hope this helps,

If you are running Windows, you can invoke the .exe using the SystemExec.vi in the Communication Pallette. This VI will let you execute any DOS command with parameters, just invoke the Perl code using the command input. By the way, you should also look at the following link to see about interfacing to Perl without building the Perl code into an executable. <http://www.jeffreytravis.com/lost/labperl.html> Hope this helps,

Search on the National Instruments website for what you want, or go to http://www.searchview.net and search there.

There are many ways to do this, 1. Look at the Analyze pallette on the block diagram, there is a Mathmatics pallette that has lots of stuff, including the ability to use custom math, and there is a bunch of Transfer functions for both the Time domain and Frequency domain under the signal processing pallette. 2. You can look at the LabVIEW Control & Design Toolkit fron NI. This is an additional package that includes many add-on VI's that will do calculation on transfer functions. 3. If you have a complicated formula or function in Matlab, Simulink, or some of the other programs, you can interface to them as compiled DLL's. 4. Or you can use the NI Simulation Interface Toolkit, which is also an add-on toolkit. It sort of depends on what software you have and what you are comfortable with. Hope this helps,

You can make a simple password pop-up window by using the Prompt User For Input VI, it is an express VI on the Time & Dialog controls. You can configure it to return a string to your VI, then compare it to the actual password. You could use the File I/O VI's to make a password file, and read it into the VI before you prompt the user, so the password is not actually stored in the VI.

First, I would suggest you look at the Labview State Diagram Toolkit. This is an additional package you add to LabVIEW to automatically generate LabVIEW code based on a state Diagram you design. Have a look here for details <http://sine.ni.com/apps/we/nioc.vp?cid=12314〈=US> (or look for the State Diagram Toolkit at the NI website.) Second, many experienced labview programmers will make their own state diagram template, usually based on using the Case Structure on the block diagram, there are many types available, some are free, and others will cost you.

And, if you feel like changing that serial number, you can do that too! Check out the VolumeID utility from sysinternals <http://www.sysinternals.com/files/volid.zip> You could even call it via Command Line from Labview!

We have found 1024 x 768 is usually a good size, because that is what most older computers will handle, even if my laptop can do much better. It helps to keep in mind what computer your product will run on, if it is an old computer, expect a smaller resolution. One other thing to keep in mind is the consistency of writing code, if you get into the habit of always doing good diagrams it really takes care of itself. I have also found it is a good thing to go back occasionally over my code, I am always finding a place I can clean up that will take out extra space in my diagram. I have worked on programs in the past that had strict coding standard requirements that dictated this also. It had strict rules like requiring ALL connector panes to be 4x2x2x4 (bottom row, third one from left) regardless of number of terminals, and a specific maximum number of VI's allowed on the block diagram. It really depends on what your reqirements are.

It looks like you could the VI's to make event notifications with Labview, the Vevent structure will notify when you have a message to read, write, or other events. You just have to be willing to do some work on correctly configuring the events via labview before you start the run tasks, the Examples. You might also want to increase the RXqueue size for the system if you have a large amount of CAN traffic, it looks like it could be increased up to 1024 messages. This would allow you to poll at a slower rate with less worry about losing messages. I typically run with CAN receive queues defined for anywhere between 100 to 300 elements, mainly due to the fact that the Windows based timing can show problems.

The first thing we really need to know is how are you trying to interface to the CANcard. Are you using the DLL or are you trying to use some sort of activeX object or method? I have experience with the CANcard.DLL, you can interface to it using the methods listed in the back of the CAN driver manual. You can only read the card when NO other CAN applications are running, including CANalyzer or CANoe. There is a ActiveX method to interface to the CANalyzer/CANoe software, but it seemed like a slow limited method when I tried it. I mention this because each method is completely different in what you can do for filtering Back to your question You can make an object or notifier that will inform you when a specific message is found, but be aware that it will not work like normal. You will usually have to poll all messages found in the CAN receive buffer, then loop thru them until you find the message you are looking for. If you set the CAN mask and filter to be extremely tight, you can filter for only that message, then poll the CAN interface until you find it. I would suggest reading the manual that came with the CAN card. P.S. The Vector people have a library of VI's for interfacing to Labview, but you can only get it if you buy a specific support package, otherwise you will have to write your own from scratch like my company did. Please repost or contact me if you have more questions

I would highly recommend read the book "A Software Engineering Approach to LabVIEW" by Jon Conway & Steve Watts ISBN 0-13-009365-3 as a primer. <http://vig.prenhall.com:8081/catalog/academic/product/0,1144,0130093653,00.html> There are lots of good and different LabVIEW books out there, here is a link to an old list: <http://www.warwicktech.freeserve.co.uk/labviewbooks.html> While you are starting this effort, you might want to start looking at a few major issues you should at least think about such as: 1. Not every VI can be written to be reuseable, but how do you want to share or reuse VI's? 2. Are you trying to use these VI's with other software? (TestStand, LabVIEW RT/FPGA, LabWindows CVI, HP-VEE, etc.) 3. What type of source code control are you using? (You should be definitely looking at using source code control if you have more than 1 user using the same VI's 4. How are you going to share them, over a network or server, seperate copies, etc. 5. Which Labview Versions will you support? 6.1,7.0,7.1,.... Keep in mid that each company will have slightly different ideas and practices, you need to try it until you find something that works for you

there are many ways to do this. 1. You can use basic math to do a simple encryption on the password. One of the most common ways involves taking the password input from a string control, converting the string to ASCII data, then run it into boolean math. (XOR, shifting, or inversion) The good part of this system is that it is easy to code, it executes quickly, and the password string is not explicity saved in the VI. 2. I have also used a hash function as a password. I input a password to a MD5 generator, then store the MD5 hash in my VI. If a user wants access to a feature, they need to input a password, and my VI will compare the MD5 result for that password to the one stored in my VI, if they match access is granted. The downside is that long calculations can get CPU intensive. You can find a MD5 VI here: <http://www.jyestudio.com/visecurity//tools.shtml> 3. You can buy authentication/security packages for Labview. There are many companies using Labview that need passwords and authentication for FDA validation. Look at the following links. <http://www.jyestudio.com/visecurity/> <http://www.colemantech.com/part11.htm> Hope this helps, DHUFF