JPrevost

Is there a way to fire an event programmatically? Ex; I open a file from a config file and put that data into an array indicator. From there I write and read using a local variable (don't worry, no chance of race condition). During the vi's running a user might change the file they want to use and so as an event I have a "value changed" event driven off of the file path change. This then fires code to load the array and do some work with it. The problem is I have that same code that does some work going on at the start of the program if there is a file found in the config file! There is now 2 repeats and no, this isn't something I can put into a subvi. The binary file data is read to a 3D chart and another loop with indicators on the main VI. My only other idea is to add another event for this case. So at the start if the binary file path is found in the config file it'll change a boolean indicator which will then fire that event of code. The only trouble with this is the location. I have the config file code as the first frame of a sequence structure with the main program loops (including event loop) running in the frame after. So this wont' work :headbang: . AAAAHHHHHHH No wonder there are programming teams. Teams being the key word.

Thanks for that refresher. I knew my best bet was going to be using a LV2 global and to bundle everything into a cluster... just didn't occure to me to use the timeout feature :headbang: . I knew timeouts were good for something

I know I should post up my code to make this easier but I don't feel it necessary yet. My delema is this; I'd like to move all of my configurable data to a seperate dialog vi. How to go about this is just beyond me right now. I know how to pass in and out of vi's but my large application uses these user configure items in multiple places. Which means I'm using local's in a lot of area's. Not a TON, less than 4 of each but there are a good 20+ configurable user values from file paths to general numeric. In the main program, it's easy because right now the local variables are just that. If I move to a seperate vi for the configurables then there will be no more locals . Oh so confusing. Maybe I should just re-write all of my code in a better architecture because right now I'm getting overwhelmed just looking at it.

So I've got hardware (as many of you know) that just streams data straight to the serial port and the PC datalogs it... trouble comes when using USB to serial adaptors. I've got 2 to experiment with, one is a Radio Shack brand, the other is Belkin. The Radio Shack adaptor crashs the whole computer system if you close the serial port while it's recieving from the hardware. This is very frustrating and from a friend, it seems to be a driver problem. Something I can't control . To get around this I've been trying to read all of the bytes waiting at the port and then quickly closing the port. So far it's been good. Only 20% crashing. Now with the Belkin I've got a whole nother problem. It doesn't want to drop any of the data. For example, even if I don't want to datalog, it backlogs into some hidden buffer! I'm thinking the only way to work around this "hidden buffer" is to read all of the bytes at the port, flush it, restart. Do this every time the user starts and stops the datalogging. So now, to make my life even harder, I've gotta look at the USB device name and figure out which device is being used. Anybody else having these issues and if so, how are you handling them?

Actually with a delay of 1ms it was synced perfectly. What is LV RTOS? Real-time Operating System? If so, I don't know. Maybe this doesn't belong in the Real-Time forum. If that's the case, sorry for the mix up although it's still weird that parallel loops run away from each other with different priority of the same operation... yes/no?

I made a simple vi that used 2 identical parallel while loops with shift registers doing an increment. Both loops were attached to local variables of a stop button. Did you know that there is no priority and the loops don't run even close to each other! One will run away fron the other . The difference ranged from .5 to 1.4 of that of the other loop. Really weird. This is with no wait ms and with a wait ms of 0ms.

Yes, this is a feedback requiring manual tuning operations. Skip a few key components like a quickly set error code from the ecm and you'll curse having missed it. That was the whole reason for developing this custom hardware and software... so that we don't miss a thing. The stock interface on these older ecm's was 160baud. 18 bytes of semi-useful data, a few useless bytes = 0.9Hz update rate . Slow? Yeah. So a friend of mine designed the heardware and some DOS software to get all the good stuff at a much faster rate. Since I'm working in the windoze xp world it's become obvious that serial ports aren't used much for daq anymore. I didn't know the events were queued. That means I can run that loop at like 10ms. Thanks. Learn something new every day. I thought that in the past, the events might be missed. Not sure why I thought that. Totally unfounded. My code isn't ready to be public but I'll give out as much as I can soon. Tomorrow is my day off, hopefully then I'll be able to post some code.

Not updating more than 5 times a second isn't an option. It needs to be 17Hz on most systems, no if ands or buts about it. The reasoning is too complicated to get into here. I'm going to try the defer panel updates property and see how that works out. 1. All my loops have a wait of either 0 or 1ms. The 0ms is for user events that I don't want to miss on even the slowest machine. 2. Working on this one. Removing the transparent objects has been tuff. I'm forcing myself to revamp the whole setup to have more uniformity. 3. When you say overlap, do you mean their rectangles made by their extreme edge or can they overlap so long as the moving parts don't overlap? I did some more thinking (yes, I do this from time to time) and I thought of a better way to do what I want. It'll just measure how long it takes to exicute the loop that updates the GUI. The queue also works well as a measure. Is it just me or do LabView's instruments take more power than even most ActiveX components? Are the newer instruments more code efficient than the classical? I didn't think they would be but apparently the newer charts/graphs are better than the classical on my machine. Maybe NI is getting better with how they write these instruments? One can only hope they aren't relying on faster machines to operate simple legacy software/hardware... I hate code bloat!

gleichman, I like your program, very easy to read but it also doesn't look like it would fit on an 800x600 resolution display. That was my problem. Before I decided to support low-po laptops I had lots of room, then I had to dumb it down which makes it look like there is no organization to my program. Look again and you'll see that there is a lot of organization considering what is being displayed. The intake air temp and engine coolant temp are grouped together in the bottom left, the speed and rpm are just above that, just like how your actual gauge cluster in the car is grouped. Then there are the flags in the upper right which are organized by color and grouped occording to other considerations (digital in/outs, oxygen sensor dependent, etc.). My stop button has been moved to the upper left hand corner and all of the buttons are self explanitory. Tool tips are everywhere and documentation is extensive. This program was ment to be easy to use when in a vehicle. The BLM's go from low to high with 128 being the mid and the background colors change to indicate without having to look at the actual number... all a little cluttered but with only a couple uses the users liked my organization. Tuning a complicated dynamic mechanical/chemical system is one thing, doing it real-time is another, helping people do it themselves is even harder, documenting, auto-learning calibrations through closed loops, etc. make it darn nere impossible to do with 1 programmer. That's why I took offense to my program being used as a do not example. If you spent a lot of time testing (over a year) would you like it if somebody came in and said, this is how not to do it without taking a closer look?

I took a look at those presentations but only briefly as this programming isn't my "job" per say. I'll take a closer look and see if I can't get some tips and direction. As for an apparent lack of organization, apparent would be the key word. Believe it or not (seems like not around here) my program is very organized. Each tab has processes information that another tab does but at the same time is specialized. Example; The VE fuel needs RPM, MAP, and BLM averaged. The main HUD shows RPM, MAP, and BLM but the BLM is instantanious! This is why I used tabs. There is a lot of redundancies and I needed it to be easy for the user to go back and forth between tabs without a lot of clicking. I'm no expert but aren't tabs suposed to be a form of organization? If that's not what I'm doing then I'm obviously in the wrong place. My code uses the tab displayed to case out the terminals that don't need updating. As in, switch away from that "busy" front tab to a different tab and the front tab gauges don't get updated. What's that called, a state machine? It's in a loop .

That is mighty speculatory. Sure my program isn't perfect but to say this is how not to use tabs is wrong. Just curious, how would you change my program to not use tabs? I also resent the comment about it coming down to the programmer's lack of creativity... that is also false. Sometimes the easiest way for a user to navigate a main program is to see all of their options at the top in a nice orderly fashion. Having beta tested my program already the only comment that was issued about the GUI was the cluttered main tab. They wanted more tabs . I am, when time allows, going to move the configure tab to it's own seperate vi. Other than that, nothing is changing unless you can give me a good reason why it should. My program is not to be navigated in order. There is a lot of data to process so I've dispatched it with tabs to keep things organized. You might also want to see what is in the other tabs before you use my program as a "how not too" example.

Never heard of this, "deferpanelupdates"

I understand completely but I I'd like to integrate a fast series of tests that can be performed on the first run of my program so it can get a "good" feel of the users current running state. There will be a warning message before this test opens that will ask the user to close all unnecessary applications and to run the test just like they would run the main program. From this simple fast test that takes less than 5 seconds on almost every machine, you can get a feeling for how fast you can update the screen. My other option was to have a feedback that monitored the queue state. If the queue got too big it would slow down the refresh rate. Do you think this is a better method?

Thank you, that was it

So I tried it today and an error popped up, "Please find the file 'Build Error Cluster___ogtk.vi" Apparently this is the only vi I don't have and I used Commander to download the package. Is it missing or what's up? How to rectify the problem. If I don't get a reply soon here I'll post on the openG forum. I just thought it was more relevent here for future search.

I thought this might be of some help or maybe just an idea. Instead of reading in a computers properties (which sometimes mean nothing), instead perform a small test or tests to measure the speed of a system. Attached is a picture of code that measures how fast a while loop will run doing a simple compare and display. You can modify it (obviously) so as not to display the iterations. I think this could be useful in my application for determining how often I refresh the GUI with new data. By performing a small speed test that is really fast on any machine, I can then, depending on the results, run an even longer test to get more accurate without killing the load time. These tests will eventually write to a cfg file with their results and the main program will use these results to determine the GUI refresh rate . Anybody use this or know of an easier way of measuring a computers speed? Running my little test program I registered the same at below and normal priority, around 5.4MHz. Above normal priority registered the lowest with 2.2MHz, and high and critical got 5.8MHz. The only explination for the "above normal priority" doing the loop the slowest was that it stopped half-way to refresh the iterations display where as the high and critical didn't even bother until the loop was finished. The below and normal updated the iterations display while running and showed a very small hit in performance. Just thought I'd share. I know there is the VI Profile under Tools_advanced, but how would one go about getting the results for later use in the VI? The VI Profile showed 1.7826s to run and my results were 1.78299s . Close enough don't you think.

Great site, good info, great people, friendly... I think this is my favorite place on the web right now! Thirdgen.org maybe a little more but I've been there since 99 and am one of their top posters... so I'm biased. :beer: :beer: :beer: :thumbup:

Let's just say the code is 4800x3000 at the moment but will NOT be getting any larger . Got a good video card, lol. It's really not that bad. Later this evening when I get some free-time I'll make a clean easy to read flow of my code that'll fit in 1 screen capture. I'm not using a wait on the display loop, only on the user event and serial/playback input loops. I thought that because of the queue, the while loop that contains the display terminals would wait at the queue and just poll it until there is something in it to output? Just a quicky question, is it better to put a wait of 0ms or 1ms or doesn't it matter?

Yup, wrong, I read about not doing that and so I don't. I wire directly to the terminal and if I can't, I'll use a local, and then those LV2 globals. Do you think it's better to run LV2 globals than locals? My program is self contained and any data I pass to a seperate VI would be to a VI's connector. I use shift registers and feedback nodes as often as I can. I'm getting better but the larger the program gets (exe is almost a meg now) the more locals I seem to have to run .

I don't get an error message, my session just freezes up. Here are the exact steps; 1. New VI 2. Placed a Chart 3. Right click on the Y scale and duplicate scale 4. Right click on the chart elsehwere (not the scales) and stack plots FREEEEEZE and LV crashs. Understandably if you reverse steps 3. and 4. you can't duplicate scale! I guess I need to find a visual of the overlay vs stepped plots means. I thought it was 2 seperate charts that share the same tools and X scale.

So I don't know if I have a problem with my install or not but here's how I replicate my error; Create a chart, duplicate the scale, stack plots (instead of overlay), instant freeze and HD activity goes high. Any ideas? I hope this is a bug with a fix because right now I'm 540miles away from the install CD's meaning it's likely I'll be SOL. Maybe it's time to upgrade to v8 If it's my install, is there a fix that somebody could send me or a file to run a hex level compare on? Ni tech support was no help Any 's?

I think you missed where I said in the 2nd sentance; "My laptop" = no PCI/AGP slots and no way to upgrade other than memory. But yes, the quick and dirty solution would be to raise the min requirements to run my program but that would take away from my target market.

How would one go about testing the differences? Could I just run a while loop full speed with some huge data and time how long it takes the i to reach some pre determined limit?

Thanks for the ideas guys (and maybe gals). I'll see what happens. My program is definatly cluttered but to an experienced tuner it's really nice to have without switching around to different views. Out of the corner of my eye I can see things while watching others. The reason I can't drop the update frequency is for playback reasons. My program plays back the data at speeds defined by the user. Slow, super fast, etc. When playing very fast the queue starts to stack up . It's tuff being the only developer for a huge program like this. I wish I had a team... but I've got this forum which I don't have to pay... yet . Again, thanks for the ideas and I will implement them and report back.

I'll try casing it out and see if it performs any better. Thanks for that apparently obvious solution :headbang: