orko

QUOTE(crelf @ Mar 14 2007, 04:56 AM)

I wonder how sanitary that red button is...

Sanitary or not...I'm just a little concerned that with a few of these installed in my work's restroom, I wouldn't get any sleep! It would sound like a construction site....

Did anyone else notice that the first "wipe cycle" produced about 1 1/2 revolutions of TP, while the next one was more like 7-8? I wonder if that's by design... ("well if they need more after that, then they probably need a lot more...")

QUOTE(Mikkel @ Mar 11 2007, 02:54 PM)

I did this a couple of years ago (in C using id3lib) for exactly the same reason...

I've done this in other languages as well, but I've honestly thought that having an MP3 library in LabVIEW might prove useful. Especially since going back to Perl or PHP for me would be similar to a Lexus owner getting back into his rusty 1970 http://www.youtube.com/watch?v=1Sn9L94YrNk' target="_blank">Toyota Hilux from High School... (bugger)

For instance, I have a library of MP3s that are added to weekly (for my church) on a web site. We need to get a podcast going so that people can set their iPods to download the updates automatically. Well, there are about 9.5Gb of MP3s that need to be tagged since no one there knew about tagging when they started the process years ago on audio cassette...

Would the tool mentioned (Tagscanner) be suitable for this? What about something else that is automated to tag and update an RSS XML file as MP3 files are dropped into the website? It seemed like I could do this in LV, but I haven't tried yet.

QUOTE(Aristos Queue @ Mar 11 2007, 03:53 PM)

Just having a bit of fun, not trying to scare anyone off.

Notice that I said I "try" to stay away.

Fortunately, the alure of what LVGOOP could do for me if I could wrap my brain around it is what keeps me coming back for more. Sorry if I sounded a bit "stand-offish" there. I was also just having a little fun by laughing at myself and my inability to simplify compound adjectives. :laugh:

The truth of the matter is that I haven't really had the time to fully explore the GOOP side of things yet. It really isn't taught through the NI courses I've taken so far (Basics,Int,Adv). Although I heard a little rumor that it *may* be considered as an Advanced II topic...

-- Joe "orko" Sines

QUOTE(Aristos Queue @ Mar 10 2007, 06:19 PM)

we might end up with a dynamic dynamic dynamic dispatch VI which overrides the default default default default value of the class.

Brain spasms resulting from clauses like this are one of the reasons why I try my hardest to stay away from the LVGOOP forum...

"Just when I thought that I was out they pull me back in."

QUOTE(tcplomp @ Mar 5 2007, 09:14 PM)

Strange, is that an NI class? because I think they should teach that with the latest release, or is everybody working on their private laptop?

Yep, I'm in Austin sitting in the class right now. We all have NI supplied Dell PCs with 8.0 installed, but even the instructors were a little surprised to find that 8.2 wasn't on the ghost image yet. They really try not to teach on a version specific level, but the course has been updated to the 8.x level.

Joe "orko" Sines

I see this thread has brought other issues to light, but back a little more on topic

In the LV Advanced class I'm in this week, there is about 10 of us that are working off of LV 8.0 boxes, and I've seen already (in the first day) several instances where LV crashed for no apparent reason on more than a few boxes... this makes me more and more reassured that I need to upgrade my apps to 8.2 as soon as I can get back to the office.

Thanks again for all of the input I've received on and off the board! Ryan King is co-teaching this class, and seemed to share the same opinion that 8.0, having brought out so many new features, was fixed in many ways by the 8.2 release.

Joe "orko" Sines

I want to thank everyone for their candid opinions on this topic. It has really put me at ease, since I've completed 2 rather large projects in the past 6(?) months that both were done in 8.0.1. I may be able to convince the powers-that-be (read: money pots) that it would be prudent to spend the time upgrading those projects to 8.2.

If not at least my new project ,which is about half-way through development, will be converted to 8.2 when I get back from LV Advanced training this next week (Austin here I come!).

Even though all of the advice was well given/taken, this quote was the clincher:

QUOTE(Aristos Queue @ Feb 28 2007, 09:44 PM)

Use 8.2. And please forgive us for 8.0. Every software team has bad days. We tried to pack ours all together in a couple months so that we wouldn't have any more bad days for the next several releases. ;-)

As a software developer, I know how hard it is to admit that all your hard work didn't pay off as well as you had planned...especially in a public forum. I really appreciate your honesty.

Joe "orko" Sines

Hello all,

A quick question for someone...

I've recently had to rebuild my dev box, and am now feeding CDs to my hungry servant (or am I it's servant...) :worship:

I've reinstalled LV7.1.1 and LV8.0.1, and am staring at my LV8.2 discs wondering...is ti time? Does anyone have any tips or pointers to information about possible issues I might run into?

Thanks!

-- orko

Thanks Ben,

Does this problem still exist in LV8.2?

Hello,

The problem that I am fighting against now in my current project can be viewed in this simple VI:

Download File:post-3266-1172249715.zip (LV8.0.1)

Basically, the problem is a real time-burner in large projects which use typedef constants a lot (for instance in queued message handlers where you are converting variant data to their typdef'd form in multiple cases). Every time you change the typedef, no matter if you have autosizing turned off or not, the constant resizes and makes a mess of the block diagram.

I believe this may be related to the following post, but his problem seemed more related to labels:

http://forums.lavag.org/index.php?showtopi...t=0&p=24425

-- orko

Michael,

Thanks for the example. However, it only gets me 75% there. Your example would work if you have two menu items that interact with each other (toggle back and forth). Its when you try and have them toggle the checkmark individually that you run into problems.

In your example, there are only two states possible: Option A checked or Option B checked. I need to have four states: both unchecked, Option A checked, Option B checked, or both checked. This is the crux of the problem since in order to change the state of these checkmarks, you need to have both the MenuRef and the selection of the user in the same event frame to know which item to check/uncheck.

Thanks PJM, I'll try that out. It would have been nice in my situation to have a static file that I can use for a bunch of similar controls...but if I can't do it that way then I have no choice.

QUOTE(PJM_labview @ Feb 15 2007, 06:19 PM)

Also, NI shipping example "Run-Time Shortcut Menus.vi" is very misleading. For instance the Menu Selection has a MenuRef output (I have no clue how to get this outside of this VI since this is not one of the event data field available [even the help does not mentioned this field]) and if you check the reference validity it is always invalid.

I see that too...that is strange to have a MenuRef in that example, but I believe you are right that you can't actually *use* it for anything, since it's invalid in that event case.

This is really annoying me that you can't change a simple checkmark on a control's runtime menu. I can trap it in the Menu Activation event as Michael suggested, and that works for detection, but I'd like to change states of the menu (even be able to change the text items displayed depending on what the user selected last). Here is an example of what I am trying to do, and how far I was able to get it using a kludge...

Sub Panel.vi (LV8.0.1)

Basically, I want to change the colors of the things the user "disables" from the right click menus available, then be able to change them back if they select it again. The checkmark would have been perfect for this, but I can't figure out how to "check" the selection when the user selection event is fired.

Is this impossible? Are there suggestions out there for how to do this a different way?

Thanks!

Hi all,

I've been beating my head against this for hours...so it's time to ask for help. :headbang:

I've created a run-time menu and saved it to disk for a numeric control with one selection item, let's say its named "foo" and is located in "menu1.rtm". I can then attach this menu to my numeric control and create an event structure handling the event: "foo: Shortcut Menu Selection (User)" to trap when someone selects this item from the menu. This works as desired.

My problem is, how can I check/uncheck the selection in the menu as I can do using the "Set Menu Item Info" menu primitives for application menus?? I don't see where I can get the MenuRef of the user rtm from within my event structure... I can only get the control reference, Item tag, Item path, and something called a "SubObj" (not at all sure what this is).

My goal is to perform one thing when the user "checks" the selection, and another when they "uncheck" it.

Thanks for any pointers!

That worked! THANK YOU!!!!

This morning I went to start up my dev environment for the *hot* project I'm working on (never fails) and I'm not getting my dev environment to launch! The LabVIEW task shows up on my task bar, but then...nothing. I let it run for 15 minutes before killing it with the task manager, then tried rebooting with the same result.

Repairing, uninstall/reinstall of LabVIEW 8.0 gives the same result. I haven't tried yet to uninstall/reinstall the whole professional dev suite, since I have LV7.1.1 on this machine as well and it is working...I'm a little hesitant to break that...

What can I do to troubleshoot this? Task manager shows LabVIEW running with ~12MB of memory and 0% CPU after trying to launch labview.exe, but I just get the task bar icon and nothing else.

Joe

Michael_Aivaliotis--> Thanks for the steps you provided. They do provide a way to resize the Xcontrol's numeric indicator, but the "container" that is dropped onto the blank VI's FP ends up still being bigger than the indicator, which means that putting say 30 of the indicators on the FP and trying to align them all up with the compression/alignment tools gets real messy. You end up doing the alignment by hand (in my case it's about 50 indicators).

tcplomp--> Argh. Not being able to put these into arrays is hampering my style... Thanks for the very timely advice.

Doon--> Good point about not being able to change the properties of elements of an array individually. Another lesson I've relearned... Your VI is very....colorful but it does illustrate a possible way I can go with this. The problem here is aligning the two arrays and all their elements perfectly so there's no "ghosting" of colors into adjoining elements.

Michael_Aivaliotis--> Yes, it does suck that you cannot have Xcontrols in arrays... but I understand what you are saying about using clusters and getting references into an array to do the coloring/blinking/etc by element positioning.

One question... Will the cluster to array primitive *always* index the resulting array corresponding to the cluster control orderring? If so, I could use this approach...

Edit: A little RTFM and yes, the cluster to array primitive does always index using the cluster order.

I'm currently involved with a project that involves displaying numerous indicators with differing values, but changing appearance (colors, flashing, bold, etc) according to the value received. It sounded like a good excuse to pursue Xcontrols, which up until now I've not found much use in my applications for. I can do this manually, but with >50 indicators refreshing as fast as possible I thought Xcontrols would be more efficient.

My problem (and it may be a silly problem but I've expended much energy on Google and LAVA to no avail) is that I'm trying to get a numeric Xcontrol indicator that takes up about 60x24 pixels, but the windows operating system seems to not want to allow resizing the front panel below 120 wide? Messing with the "Window Bounds" property of the VI seems only to temporarily solves the issue...unless I have to programmatically set up the position/size/bounds of the Xcontrol in the Init VI (which I just tried to do but must have done wrong since I crashed LV). I've tried making my Xcontrol facade big and resizing it down once on the main app's FP, but it didn't seem to work as expected. Even checking the "Maintain proportions of window" and "Scale all objects on front panel as the window resizes" options in the VI Properties of the Fa

You'll need some kind of "stop" command

Is there such a thing in LVRT that can be called from within the app?

These are configuration files used by the NI-DAQmx driver. They are used by the driver software to identify and communicate with the hardware in your system. A corrupted configuration can cause the behaviour you describe.

Thank you. That clears it up a little bit.

Now, according to this KB Article the corruption can occur when "the controller was powered off while the database was being written." If this is true, then how would I stop this from happening in the future?

I have a network of 1 host and two PXI controllers tied with an active hub. According to the PXI settings in MAX, the two PXI controllers are set to "Halt all operations when TCP/IP is lost." This would require that the active hub be turned off before the PXI power is disconnected because just turning off the host doesn't kill the connection. This is one workaround, but I'm trying to figure out what the "proper" way of halting the PXI's is. Is halting the targets something that I would have to do programatically from within my application, or is there a more surefire way of never letting this happen again?

Excuse my ignorance here, but I'm learning

Referring to this LAVA discussion I was having issues with the configuration database files that are stored on an RT target in the ni-rt/system directory. Specifically:

CONFIG.MXS

CONFIG.MXC

MXS.MXR

The LAST folder.

I did a bit of Googling and found the below thread mentioning the same

files, and was wondering if anyone had more insight of *what* these

files are used for on an RT target and *why* they would cause a system

to fail startup until they were deleted (this is what fixed my

problem). It seems that during startup the files are recreated if not

there, but I have no idea what they are used for... Can someone shed

some light on this so I can at least sound a little intelligible to my

superiors when they ask?

This post in Google also suggests that NI can use the files to

troubleshoot a RT bootup issue...

Thanks in advance!

Joe "orko" Sines

Maybe I'm missing something here

Yes, I was missing something too I was assuming that we had all we needed on the host machine, but was very perterbed to find out that we neither had the recovery CDs, nor the LV RT dev environment! Ugh. Evidently the contractors left us with nothing to fix the system with!

Anyway, GOOD NEWS! I was googling and ran across a KB that dealt with a different problem, but I'm thinking that it had the same cause. It can be found Here. Deleting the files mentioned in the KB and rebooting both PXI controllers re-initialized these configuration database files and both of them booted normally!

According to the KB above, these files may become corrupt when power is removed during read/write access to them. I think this is what happened to my first controller. As far as I can tell, when the second controller's hard drive was put in the suspect controller, it got confused because the configuration files stored didn't match the controller it was in (??)

This is a learning experience, to say the least. These configuration database files are in my mind akin to "registry" files that everone should be aware of. Stumbling onto this KB article was pure luck for me since it looked like it only applied to one kind of error. It seems like they would also have a "PXI chassis reboots three times and fails to Safe Mode" KB with the above procedure to try... this really saved my hide!

Thanks for all your responses, and I hope this thread can help someone in the future.

You might want to look at this, it may be possible to reinstall from files on disk

http://zone.ni.com/devzone/conceptd.nsf/we...6256D080074AD58

(search for PXI system reinstall)

never did this myself, thought I might need to but didn't.

Thanks! I found that and was excited...but then shortly afterward was shot down when I found that there wasn't an /images directory on my HDD.

The first and easiest thing to check is what you have installed on the RT side. If you have NI-IMAQ and NI-IMAQ-1394 installed at the same time, there could be a hang at bootup. That is a known issue, although I have not seen any fix for it. The workaround is to only have one or the other installed... or neither if you do not need image acquisition.

We are not using IMAQ

If you do not have IMAQ or IMAQ-1394, the problem could be VISA. There has been a rash of new VISA versions lately, and you could make sure you're on the latest and greatest.

I'll check to see...

What version of everything are you using now?

From MAX:

LV Realtime 7.1

NI-VISA Server 3.2

NI-VISA 3.2

NI-DAQmx 7.3.0

Traditional NI-DAQ 7.3.0

Language support for LV RT 1.0.0.1

Is there some way that a driver configuration of VISA or otherwise could cause a RT controller not to boot? I'm trying to wrap my brain around this, but am having difficulty figuring out what would cause a reboot in the exact same spot when I swapped the known good hard drive into the suspect controller... :headbang:

Fellow RT firefighters,

I have a rack with two PXI-1010 chassis housing identical PXI-8176 controllers. They are configured identically (same versions of the RT engine, VISA, etc).

One of the controllers decided one day to not boot. It will get past the network initialization, but hang before (or during...not sure) the NI-VISA server startup. In other words it would not display the NI-VISA startup text. It will reboot three times after power up at the same spot, then sit in safe mode. I am able then to FTP in and have backed up the whole disk by downloading all of the folders/files with no issue. BTW, turning on the extended memory check in BIOS doesn't produce any failures on boot.

The other controller was working, and booting the NI-VISA server and starting the LabVIEW RT-OS just fine. By swapping the good controller with the bad, I was able to isolate the problem down to the controller itself and not the chassis. Memory swap between controllers didn't change the symptoms. Seeing that the hardware was identical on each controller, and the software installed was identical except for the configuration files for the modules, I decided to swap the HDD from the bad controller into the good to verify that the HDD or software was the cause of the lockups. It exhibited the same lockup issues in the good controller as expected. I then installed the good HDD in the bad controller...my mistake. It now exhibits the same lockups! Swapping it back to its original controller it is now acting exactly like the other one, rebooting at the same point...

Now I have two bad controllers... so on one hand it looks like the first controller that went bad has a bad IDE interface that is corrupting data(?). But that seems unlikely since the symptoms that it caused are exactly the same at the same point of bootup... this almost looks like a bad driver or software related failure, but then how did the good HDD get messed up all by itself when installed into the suspect controller? These are Fujitsu 20GB hard drives BTW and worked fine when they were first set up.

Now another point to mention is that the recovery CD's for the PXI controller are nowhere to be found. We suspect a contractor has them in their desk somewhere, but the main thing is getting one so we can attempt to resurrect the originally "GOOD" controller. Does anyone know where I could get/download a copy?

I've never done a reload before, but reading into it, it appears that we would be able to boot off of a DOS boot disk w/network support and map a remote CDROM as a shared drive to start the recovery.bat process. Then transfer over the target application software from our backups we made.

If I'm missing anything or you have any ideas, please someone provide some insight! I know this is probably something that has occurred with a handful of you at one point or another. ;-)

THANKS IN ADVANCE! WE ARE CURRENTLY IN "HOT" MODE TO FIX THIS, SO I WOULD WHOLE-HEARTEDLY APPRECIATE ANY FEEDBACK YOU MAY HAVE. FEEL FREE TO DIRECTLY EMAIL ME.

Joe Sines

SinesJP@kpt.nuwc.navy.mil