Dachenday

Thank you for the responses! I think I have gotten it working by just deleting sections and rewiring them in a different way. This time I had to redo a section of code that allows the user to choose the name of the save file he's later going to create. It took me so long to find it because that section of code was inside step 10 of a sequence structure, and the program would stop running in step 14. "The sorts of problems you're describing are the deepest dread of compiler writers -- they might be user error, they might be our fault, neither you nor we can tell at the moment, and the longer it goes on, the more it will undercut your confidence in our language" I've only been programming in labview for a few months, and NI has been around for considerably longer ,so I'm pretty sure that I just did something wrong. I realize that it's possible that I found some glitch, but I'm not arrogant enough to think that that's likely. "(BTW: that is why in my opinion EEs make better LabVIEW programmers than CS majors. We just naturally think in terms of races and not syntax.) " Actually, I'm a BME, not a EE. Hey.... maybe that's my problem!

By ghosts I don't mean anything supernatural, but rather a certain phenomena I have witnessed various times in labview. One of my previous programs had a strange issue when every now and then it simply wouldn't work. It would compile just fine ( the run arrow wasn't broken) but it wouldn't work. I discovered that if I go into the block diagram, and delete any wire, it didn't matter which one, and redraw it exactly like it was before, then my program worked just fine. From this I made 3 hypothesis: 1- my code was compiling, but just barely. That there is something going on inside of labview that runs on a "lower" level than the block diagram. 2-That I had programed my code so badly that my program was sitting on a "knife edge" and that sometimes this lower level compiling worked fine and sometimes it didn't. 3-That by deleting and recreating any part of the block diagram I was forcing this lower level code to recompile and end up or the right side of the "knife edge" I guessed that there were some elements of this lower level program that changed with each compile, and I termed these things ghosts, because whatever they are (if they even exist) they are not visible on the block diagram. Eventually these ghosts went away, and I figured that meant that I had changed the block diagram enough to step away from the knife edge, but now I'm not so sure. My current program, which was built on the previously mentioned program, used to cause labview to shut down as soon as the run button was pushed. I went into the block diagram and started removing things, hoping that eventually I could get labview to not commit seppuku every time I tried to run the program. I removed several sections of "vestigial" code (my term for pieces of code that don't do anything anymore, and that are simply left over from previous versions). I had left these sections in because as I said, they didn't do anything, so there was no reason to remove them yet. (I would have removed them when the program was finished, simply to clean up the block diagram) After I had removed the vestigial sections the program still wouldn't work, so I started removing important stuff. Eventually it ran, so I put the important stuff back, and strangely enough, it still worked. Now every time I run my program it goes really slowly. As before I started removing things until it worked, and eventually got something working (by that point I had removed lots of vital stuff, so leaving it in that state wasn't an option). However I though that I had figured out which part of my code was causing the problem, it was a build array vi that combined 32 1dimensional arrays into a 2 dimensional array. I wasn't sure how that could be causing a problem, but I figured I'd just find another way to combine the arrays. The really strange thing is that now my program won't run even without the build array vi. It's like the opposite of the deleting and recreating the wire I mentioned previously, i that any save that I doesn't have the build array vi works fine, but any save that I add the build array vi into won't work, even if I remove the build array vi. My question is : am I right about these "ghosts" and if I am how do I solve problems that aren't on the block diagram? I'm sorry that I can't post my code ( that's why I made such a long post describing my problems, but I realize code would have been better) I also understand if nobody can help me without my code, but I figured that it couldn't hurt to ask.

I got it to stop shutting down, but I'm not sure why it stopped. I was following Ton's advice and deleting sections of the diagram until it would run (I saved a copy first). I got it to work, and it seems that the problem occurred in the course of adding loadcell data to an array and then saving the array. There are two things that I found strange about this. The first thing is that I had made no recent changes to that section of my diagram. The second thing is that I then re-wired that section and it now works. I've had things like that happen before (I call them ghosts) but I'd never seen my programs just shut down labview. I tried to run the program several times before selectively deleting sections ( I would estimate over a dozen), and each time it just shut down. Then I delete a section and rewire it and it no longer shuts down. I still don't understand why it happened.

Hello everybody. I have a very strange problem, and I was hoping that maybe somebody would be able to help me. Unfortuantly, I'm pretty sure I can't post my code for ethical and possibly legal reasons. (I'm being paid to write it for a company) Anyway, my problem is that every time I hit the run button, labview just shuts down. I've had programs crash before, and usually when I restart labview a message pops up that says that labview shut down improperly, and asks if I want to recover my programs, but not in this case. Every time I google labview shut down I keep getting results that have to do with intentionally shutting down the computer or other programs, so I thought I would ask for help here. Has anybody ever seen anything like this?

Sorry for the long delay (school just started back, and I'm finishing off my undergraduate degree). Sorry for not posting my code, but I'm not sure if it is appropriate or not (Since I'm being paid to write it, I'm not even sure who owns it, I'm pretty new at this). But thank you very much for the help, I do appreciate it.

Thanks for the help, everybody. I got it working

"Alternatively, you can use the Number to Boolean Array to convert your U8 to an array of 8 Booleans."- Saverio, 1/8/2011 That sounds perfect, thanks. I'll try that. (This computer doesn't have labview) Thank you responding so quickly.

thanks for the info. Fortunately, the company did send me everything I need to interface with and control the loadcell. I do have a new problem though, and I would appreciate advice on the matter. When I stream the data in from the loadcell, in comes in as a hexadecimal number with a range of 0 to 255. however, most of those bits do not contain information, and are merely used to confirm which device is being used and other stuff like that. My first thought was to change the hexadecimal into binary, and then to put every bit into an array, and then use the index array function to read the bits I need. However I have not been able to find a way to treat the hexadecimal number as 8 separate bits. I would appreciate any advice you could offer.

The only thing that changes when I plug it in, as far as I can tell, is that something called "USB serial converter" pops up. There's nothing in the properties of the serial converter that would suggest that it's related to the ergopak, but it does go away when I unplug the usb. I recently got in contact with the company, and they seem willing to help, so that's good EDIT I've used memory addresses to read information before, but that what was on micro controllers. Can I read information from memory addresses on PCs the same way, and if so can I read the info with labview?

Hoggan manufactures it. Here's a website that sells it http://www.hogganhealth.com/microfet-ergonomics2.php?product=ergoPAK The loadcell has a cable coming out of it that attaches to a short range transceiver, which communicates with another transceiver that's plugged into one of the computer's USB ports. Thank you for responding so quickly.

Hello everybody. I'm an engineering intern working in labview. I've only been using labview for a few months, so I'm really new at it. Anyway, I need to find a way to read the data off of a loadcell using labview. The loadcell is part of a kit called ergopak, and it does come with a program to control it. I'm pretty sure I can use preprogramed mouse movements and mouse clicks to control the other program, but my boss would prefer for me to be able to read the address space where the loadcell stores it's data. The loadcell communicated wirelessly with a usb that is plugged into the computer. I've emailed the company that makes the loadcell 3 times, once asking if the loadcell could be controlled by labview, once asking if it could be controlled by DDE, and once asking which address space the loadcell uses. They told me that it can't be controlled by labview, but haven't responded to the other emails yet. I would really appreciate any advice at all.