JPrevost

I haven't done 3-axis accelerometer daq and graphing but I have done 2-axis. It was a custom circuit using an inexpensive AD ic which went into an A/D circuit which went into the computer through rs232. Save that vi in v7.0 for me so I can see what you have so far. Do you want to display all 3-axis in a 3D chart or just line chart each axis as a 2D line chart? With my plotter/data logger I simply displayed the data in an XY plot and used some history to plot the a trail of points. If you ever saw the "G-meter" in a Nissan Skyline GTR it looked just like it. Only it was displayed on a much larger screen (16" laptop). In parallel there was a loop that would monitor the "log to disk" button and when "on" it would simply write to a file in spreadsheet format.

Jason, thank you for the reply. I should have been more specific but yes, I think it would be nice if LV could use DirectX if it isn't currently doing so. What is the 3D graphing doing when "Use3DHardwareAcceleration" is set to True? Why is it the only indicator with this property? I have an application that displays data rather fast and from an older post it was discovered that the graphics were all being rendered in software mode . Is this only for the 2D controls and indicators? Having some kind of option for the programmer to design software for a specific platform would be nice.

I would be really happy if LV start supporting hardware video acceleration. Sometimes we write programs ment for a specific OS, like Windows for example, and we're working with older computers that have weak processors but decent under-utilized graphics cards. It would be awesome to have this support for those of us with large applications that don't want to go with purchasing active-x controls (which aren't much better). The majority of computers now-a-days have video acceleration so when the program is run local (often is in my case) then let it use the muscle it's got. Right now I feel like LV is Lance Armstrong in an arm wrestling competition... he ain't so "arm" strong but the legs... yeeeeaaaaaah.

rolfk, v7.0 over here

. I didn't know you could wire a string to the resource name terminal of the serial open subvi. :worship: That's the set up MY system, not the system the compiled program is running on! I have no trouble with the alias names... it's the end users that get confused.

Update: Hasn't crashed since. Thanks for the suggestions!

Okay, I understand how to do that but I'm still left with trying to display to the user the friendly names as a control for the config serial. Sure I can get the names but how to list them and open the serial port is where I'm stuck.

Tell me what you've got, what you want to do and maybe I can be of some help. I've worked with custom hardware and OEM ECM hardware. CAN would be a pain if you're not getting direct support from the ECM manufacturer and so I would recommend custom NI hardware. The best thing you can do when working with IC engines is to know what you want to do before buying anything. Certain testing requires very fast daq, some things like tuning can be done with relatively slow daq.

Okay. I'll try it out. BTW, version 7.1 > 7.0 ... still can't open

<-- version 7.0, not 8 but yes, I follow what you're saying. Last week was the first time I did what you just said with the cluster constant labeling. I'm thinking about using that for the configure part of of my program only I don't like the idea of having a configure.vi that requires passing a huge cluster to write but then when reading, having to read the WHOLE cluster (over 40 elements) just to read 1. This is why I'm still using local variables and sequence structuring to initially read the cfg file in, update the controls, then read them all over the program using local variables. Do you think I should use a seperate configure vi with a functional/LV2 global? These user configurables are read relatively often and relatively fast ~10 get read in different locations of the program >17Hz. It would really clean up the main vi if I did go to clustering and a seperate config vi but I don't want to do it if it'll hurt performance any (suporting slow ~400Mhz machines). Thanks again for that reminder about labeling... I still wish it was easier to label wires. Like a right-click shortcut label feature :2cents: .

You mean, after I parse the data down into bits I should build them into a new array, pass that into the case structure and pull out only what I need that way? That could work except that every time I add something that is imbetween (indexed all over the place) I would need to rewire everything . If it's faster I'll do it. I'm just trying to make the program maintanable at this point and will be adding to it in the future as updates to the hardware get released. What do you think about the subpanel. Is it bad practice to use sub panels if you only plan on loading 1 vi?

Labeling an indexed array item... notice how it has no name is defaulted to "numeric" for every item. Only if I wire it to an indicator does it get a name .

<-- dealing with 200+ items that are used by the user to help control the system (engine fuel/spark controller). Passing data comes from reading in a bunch of bytes from the serial buffer and then parsing out the bytes to subvi's that do the conversion work. Some bytes are broken down into bits and this is where the wires start to get crazy. I have over 170 bits that will eventually be passed on to the user in some form or another. Currently I'm working with about 100 and the wires are getting a bit out of hand. Some of the flags aren't used for anything special and so they are broken out of the byte array (full data packet) within the case structure making it easier but some of the bits are used for things like autotuning meaning its status needs to be read outside of the case. This is where it gets nasty. Wires going everywhere. Bundling them into a cluster would help. These are only boolean so from the sounds of it, the performance hit shouldn't even be measurable...

I thought FG were used to talk between vi's where as locals are used to talk within a single vi but multiple loops. I have no need to call the locals globally. Right now I'm using a local as a place holder. While data is being played back a slider is indicating the seek location of the file. When a user clicks on the slide I have it setup so it writes the new value to a local which is then called by a queue in the loop that does the file seeking. If that isn't clear I'll post images of the code. As for naming a indexed array item I'm talking about giving that single element a name without wiring it to an indicator so that it can be clustered with a name. Again, if that isn't clear I'm sure it's my fault and I'll be more than happy to post an example. Thanks for the replies so far and yes, I could use a FG but I thought they should be used when calling by seperate vi's... if it's more efficient than using a hidden FP object and queue then I'll do it . It would clear up the wiring diaghram.

I'd like it if there were local's that didn't have a front panel item to hide. I use them infrequently but in large applications they seem to be the best way to sync parallel loops. I also think there should be a way to label an indexed array item. There is no way to do this right now in 7.0, maybe in 7.1?