Jump to content

JPrevost

Members
  • Content Count

    61
  • Joined

  • Last visited

Community Reputation

0

About JPrevost

  • Rank
    Very Active

Profile Information

  • Gender
    Not Telling

LabVIEW Information

  • Version
    LabVIEW 2012
  • Since
    2001
  1. 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 l
  2. 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.
  3. 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 lik
  4. . 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.
  5. Update: Hasn't crashed since. Thanks for the suggestions!
  6. 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.
  7. 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.
  8. Okay. I'll try it out. BTW, version 7.1 > 7.0 ... still can't open
  9. <-- 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
  10. 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?
  11. 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 .
  12. <-- 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
  13. 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 wir
  14. 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?
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.