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,