Jump to content

JPrevost

Members
  • Posts

    61
  • Joined

  • Last visited

Everything posted by JPrevost

  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 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.
  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 like LV is Lance Armstrong in an arm wrestling competition... he ain't so "arm" strong but the legs... yeeeeaaaaaah.
  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 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: .
  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 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...
  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 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.
  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?
  15. Thanks. I guess I'm running into something else as my problem, not the OpenG VI's. Apparently the paths get all screwed up when dealing with vi's vs compiled exe's. I was changing the extension from .vi to .cfg for the config file but it wasn't working with .exe, oh well, this is going to waste my time figuring it out . As for the subpanels, this is where I would bundle the many (20+) boolean data and send it to the vi that's embedded in a subpanel. From your reply, it sounds like bundling anything into clusters does do a hit on the performance... so I'll avoid it. Now the question goes back to the seperate vi for config data. How else is one suposed to send a LOT and read frequently from a seperate vi if not for clusters. It almost makes me wonder if I shouldn't stick to keeping the user configurables built into the main vi for faster recall.
  16. Maybe I'm missing something easy but how does one go about displaying only found and avail serial ports to the user in a nice "user friendly" name like COM1 instead of ASRL1::INSTR. Thanks in advance. I did user the; [ALIASES] Alias0 = "'LPT1','ASRL10::INSTR'" Alias1 = "'COM1','ASRL1::INSTR'" Alias2 = "'COM2','ASRL2::INSTR'" Alias3 = "'COM3','ASRL3::INSTR'" Alias4 = "'COM4','ASRL4::INSTR'" Alias5 = "'COM5','ASRL5::INSTR'" Alias6 = "'COM6','ASRL6::INSTR'" Alias7 = "'COM7','ASRL7::INSTR'" Alias8 = "'COM8','ASRL8::INSTR'" NumAliases = 9 to get those friendly names but now they're ALL listed to the user when only a couple are really there. My other alternative is to do a polling of the serial ports to see which one is most likely the port with the hardware connected... totally removing the user from the picture
  17. So here I am still streamlining my program to be smaller and easier to modify. First question should be easy; do clusters effect the performance of a program? Example; Passing multiple wires into a case structure vs. putting them in a cluster and while in the case, unbundle by name to an indicator? Second question, subpanels. When is it a good idea to use them. My program has an area that displays boolean data as FP LEDs and they only get written too. Would it benifit me in any way to make a seperate VI for them, use a cluster, and call the VI into a subpanel? I wish I knew more about how certain things effect program performance. Third question; When using OpenG vi's, after compiling with LabView's application builder, do the users have to do a full install or can they just copy the new exe into the program directory? Or do I have to do more? I ask because I'm using the extension replace vi to change the .exe to .cfg for user config data to be saved but during builds, the more I use OpenG the more beta testers complain of broken features
  18. 4096/256=16 bytes which might be a limitation in supporting a wide array of hardware and OS. Although it's odd because scrolling isn't anything new. http://www.displaymate.com/infodmm.html That isn't an answer but it might be something to do with the OS support. I wonder if this is the same limitation in LV8.
  19. I'm wrong on one account. This probably won't be my best program but it is my first. Key word being my. The only other "program" I've written in LabView was some crap that did nothing more than subroutine, woops, subvi "work". My first intro to LabView was v6 back in 03 where I was in charge of setting up an enging dc electric engine dyno in the ME department of Ohio State University... I was a student on the FSAE team. Some student before me wrote a program that datalogged but it was poorely written. I didn't have any documentation and just started playing around with it after class every day for a couple months. After finally taking a NI class things started to click together in my brain and off I was running. Even then I didn't write a new program, I just modified the existing one. I too can think of a few ways to move data between loops but the local variables seem the best when they're called in multiple places at different times without any order (user input/interrupts). I like Queues and I think they are the best. Nothing lost and very flexible except I'm not at the level of using them to pass jobs between loops. Eventually, I hope. I totally understand what you guys are saying about the event structure. That's what I was trying to say only I didn't do a good job with it. The less work the event structure has to do the better and so I can have a LOT of cases, just don't add a lot of code .
  20. I'm looking at using queue's soon. I like how the loops wait until there is something in a queue. This is by far the best part about them. I'm using a queue to take data from either the serial port or a file, if the data is checksumed as OK it goes into the queue, if not, empty case . Thanks for that suggestion about using queues to pass work around. Right now I've only got it passing data between 2 loops, the "producer consumer" architecture only the producer isn't an event structure.... yet!
  21. Thanks for the reply and the direction. I'm working on always improving this code. It is my first large application and it will be my best! As for the code size. I shouldn't have said 1mb. That's just the exe after building. As you know I've been battling the graphical side of LabView. That's my biggest hang-up because when I time the VI's they're all running with great efficiency. I've converted a lot of my "make the wiring diaghram smaller vi's" to subvi execution, this doesn't seem to register any measurable gains but I'm sure it's there if I look hard enough. I've got a bunch of local variables but I use them sparingly. Next step is getting the config file to a seperate vi where I'm going to use your example as a template. Other than that I'm moving a lot of my code into the event structure. The problem with this is sharing data between other parallel loops. The only means possible is through use of locals . I'm going to try and get you a copy of my code asap. I just spent the weekend pounding out a new beta release that fixed some of the complaints so I should have some time to give you a better picture. BTW, what I think you're doing is awesome. I can't thank you enough... maybe I'll fly out to one of these NI gatherings. Not anytime soon but eventually
  22. What should I do to speed things up? I'm only using com ports 1-4. I don't plan on using anything but the serial port. It's funny you mention this file. I was here last week to create the alias naming after a beta tester said they didn't like the name of the com ports being all "fancy shmancy." My file contains; [VISA-CONFIG]MinAsyncCount = 512SharedMemSize = 131072MaxNumResources = 256NumSystemSems = 512NumProcessSems = 256AlwaysRefresh = 0UnloadPassports = 0[GPIB-CONFIG]DisableIbListen = 0SRQPollTime = 500EnetConnectTmoSec = 6Board0 = 1Board1 = 1Board2 = 1Board3 = 1Board4 = 1Board5 = 1Board6 = 1Board7 = 1Board8 = 1Board9 = 1Board10 = 1Board11 = 1Board12 = 1Board13 = 1Board14 = 1Board15 = 1Board16 = 1Board17 = 1Board18 = 1Board19 = 1Board20 = 1Board21 = 1Board22 = 1Board23 = 1Board24 = 1Board25 = 1Board26 = 1Board27 = 1Board28 = 1Board29 = 1Board30 = 1Board31 = 1Board32 = 1Board33 = 1Board34 = 1Board35 = 1Board36 = 1Board37 = 1Board38 = 1Board39 = 1Board40 = 1Board41 = 1Board42 = 1Board43 = 1Board44 = 1Board45 = 1Board46 = 1Board47 = 1Board48 = 1Board49 = 1Board50 = 1Board51 = 1Board52 = 1Board53 = 1Board54 = 1Board55 = 1Board56 = 1Board57 = 1Board58 = 1Board59 = 1Board60 = 1Board61 = 1Board62 = 1Board63 = 1Board64 = 1Board65 = 1Board66 = 1Board67 = 1Board68 = 1Board69 = 1Board70 = 1Board71 = 1Board72 = 1Board73 = 1Board74 = 1Board75 = 1Board76 = 1Board77 = 1Board78 = 1Board79 = 1Board80 = 1Board81 = 1Board82 = 1Board83 = 1Board84 = 1Board85 = 1Board86 = 1Board87 = 1Board88 = 1Board89 = 1Board90 = 1Board91 = 1Board92 = 1Board93 = 1Board94 = 1Board95 = 1Board96 = 1Board97 = 1Board98 = 1Board99 = 1[GPIB-VXI-CONFIG]StartDebug = 0DisableAutoFind = 0RetryAfterFailure = 1[TULIP-CONFIG]UseAgilentVisa = 1NativeTypesOnly = 1SynchronizeAllVxi = 0SynchronizeAllGpib = 1Interface0 = 1Interface1 = 1Interface2 = 1Interface3 = 1Interface4 = 1Interface5 = 1Interface6 = 1Interface7 = 1Interface8 = 1Interface9 = 1Interface10 = 1Interface11 = 1Interface12 = 1Interface13 = 1Interface14 = 1Interface15 = 1Interface16 = 1Interface17 = 1Interface18 = 1Interface19 = 1Interface20 = 1Interface21 = 1Interface22 = 1Interface23 = 1Interface24 = 1Interface25 = 1Interface26 = 1Interface27 = 1Interface28 = 1Interface29 = 1Interface30 = 1Interface31 = 1Interface32 = 1Interface33 = 1Interface34 = 1Interface35 = 1Interface36 = 1Interface37 = 1Interface38 = 1Interface39 = 1Interface40 = 1Interface41 = 1Interface42 = 1Interface43 = 1Interface44 = 1Interface45 = 1Interface46 = 1Interface47 = 1Interface48 = 1Interface49 = 1Interface50 = 1Interface51 = 1Interface52 = 1Interface53 = 1Interface54 = 1Interface55 = 1Interface56 = 1Interface57 = 1Interface58 = 1Interface59 = 1Interface60 = 1Interface61 = 1Interface62 = 1Interface63 = 1Interface64 = 1Interface65 = 1Interface66 = 1Interface67 = 1Interface68 = 1Interface69 = 1Interface70 = 1Interface71 = 1Interface72 = 1Interface73 = 1Interface74 = 1Interface75 = 1Interface76 = 1Interface77 = 1Interface78 = 1Interface79 = 1Interface80 = 1Interface81 = 1Interface82 = 1Interface83 = 1Interface84 = 1Interface85 = 1Interface86 = 1Interface87 = 1Interface88 = 1Interface89 = 1Interface90 = 1Interface91 = 1Interface92 = 1Interface93 = 1Interface94 = 1Interface95 = 1Interface96 = 1Interface97 = 1Interface98 = 1Interface99 = 1Interface100 = 1Interface101 = 1Interface102 = 1Interface103 = 1Interface104 = 1Interface105 = 1Interface106 = 1Interface107 = 1Interface108 = 1Interface109 = 1Interface110 = 1Interface111 = 1Interface112 = 1Interface113 = 1Interface114 = 1Interface115 = 1Interface116 = 1Interface117 = 1Interface118 = 1Interface119 = 1Interface120 = 1Interface121 = 1Interface122 = 1Interface123 = 1Interface124 = 1Interface125 = 1Interface126 = 1Interface127 = 1Interface128 = 1Interface129 = 1Interface130 = 1Interface131 = 1Interface132 = 1Interface133 = 1Interface134 = 1Interface135 = 1Interface136 = 1Interface137 = 1Interface138 = 1Interface139 = 1Interface140 = 1Interface141 = 1Interface142 = 1Interface143 = 1Interface144 = 1Interface145 = 1Interface146 = 1Interface147 = 1Interface148 = 1Interface149 = 1Interface150 = 1Interface151 = 1Interface152 = 1Interface153 = 1Interface154 = 1Interface155 = 1Interface156 = 1Interface157 = 1Interface158 = 1Interface159 = 1Interface160 = 1Interface161 = 1Interface162 = 1Interface163 = 1Interface164 = 1Interface165 = 1Interface166 = 1Interface167 = 1Interface168 = 1Interface169 = 1Interface170 = 1Interface171 = 1Interface172 = 1Interface173 = 1Interface174 = 1Interface175 = 1Interface176 = 1Interface177 = 1Interface178 = 1Interface179 = 1Interface180 = 1Interface181 = 1Interface182 = 1Interface183 = 1Interface184 = 1Interface185 = 1Interface186 = 1Interface187 = 1Interface188 = 1Interface189 = 1Interface190 = 1Interface191 = 1Interface192 = 1Interface193 = 1Interface194 = 1Interface195 = 1Interface196 = 1Interface197 = 1Interface198 = 1Interface199 = 1Interface200 = 1Interface201 = 1Interface202 = 1Interface203 = 1Interface204 = 1Interface205 = 1Interface206 = 1Interface207 = 1Interface208 = 1Interface209 = 1Interface210 = 1Interface211 = 1Interface212 = 1Interface213 = 1Interface214 = 1Interface215 = 1Interface216 = 1Interface217 = 1Interface218 = 1Interface219 = 1Interface220 = 1Interface221 = 1Interface222 = 1Interface223 = 1Interface224 = 1Interface225 = 1Interface226 = 1Interface227 = 1Interface228 = 1Interface229 = 1Interface230 = 1Interface231 = 1Interface232 = 1Interface233 = 1Interface234 = 1Interface235 = 1Interface236 = 1Interface237 = 1Interface238 = 1Interface239 = 1Interface240 = 1Interface241 = 1Interface242 = 1Interface243 = 1Interface244 = 1Interface245 = 1Interface246 = 1Interface247 = 1Interface248 = 1Interface249 = 1Interface250 = 1Interface251 = 1Interface252 = 1Interface253 = 1Interface254 = 1Interface255 = 1[PXI-CONFIG]ShowRegisteredDevOnly = 1[TCPIP-RSRCS]SynchronizeAllSocket = 0SynchronizeAllVxi11 = 1NumOfResources = 0[ALIASES]Alias0 = "'LPT1','ASRL10::INSTR'"Alias1 = "'COM1','ASRL1::INSTR'"Alias2 = "'COM2','ASRL2::INSTR'"Alias3 = "'COM3','ASRL3::INSTR'"Alias4 = "'COM4','ASRL4::INSTR'"NumAliases = 5[ASRL-RSRC-ALIAS]Name0 = "ASRL10::INSTR"Enabled0 = 1Static0 = 1SystemName0 = "LPT1"BaudRate0 = 9600DataBits0 = 8Parity0 = 0StopBits0 = 10FlowCtrl0 = 0Name1 = "ASRL1::INSTR"Enabled1 = 1Static1 = 0SystemName1 = "COM1"BaudRate1 = 57600DataBits1 = 8Parity1 = 0StopBits1 = 10FlowCtrl1 = 0Name2 = "ASRL2::INSTR"Enabled2 = 1Static2 = 0SystemName2 = "COM2"BaudRate2 = 57600DataBits2 = 8Parity2 = 0StopBits2 = 10FlowCtrl2 = 0Name3 = "ASRL3::INSTR"Enabled3 = 1Static3 = 0SystemName3 = "COM3"BaudRate3 = 57600DataBits3 = 8Parity3 = 0StopBits3 = 10FlowCtrl3 = 1Name4 = "ASRL4::INSTR"Enabled4 = 1Static4 = 0SystemName4 = "COM4"BaudRate4 = 57600DataBits4 = 8Parity4 = 0StopBits4 = 10FlowCtrl4 = 0NumOfResources = 5
  23. I currently have 12 and am adding more. Is this "safe" and within good programming priniciple or am I bloating already? Having such a large program (over a meg now) is starting to really tax my concentration. Everywhere I look there is something else I need to do or test out. I'm not even adding features! Things like proper file handling (currently have 2 read, 1 create/replace/append, 1 read/write, 1 create) are really taking their toll. Because for each file there are different cases. Eg; If the user doesn't select a bin file I have to disable the learning function and disable/grey some of the tabs. If they press cancel I have special considerations like to close a file only after the user has either selected a new file or cancelled out. Thank God for error handling or I'd be one grumpy dude. Back to the event's, should I start a 2nd event structure for other events? Things that aren't directly controlled by UI? For example, if a file doesn't exist or the user cancels out of a file selection, I set a flag that indicates if there is a good file to execute code on or not. There is a case for this flag which then runs my code but at this pace I'm afraid the event structure might get flaky with so many cases. I can't remember where I read it but I believe 1 event structure is all you want in a VI. This is correct yes/no?
  24. Every once in a while I get an error in my program when in develop mode. The program has a VISA resource name control on a tab and the error happens when I've been working elsewhere and then click on the tab containing the VISA control. The whole computer hangs up a little the first time I try and go to the configure tab. I have a feeling that LabView is looking at the avail resource names to display for the user and this is why it hangs up. Is there a way to have LabView poll the resources on application startup and not when the control becomes visible? The error; nimax.exe - Application Error The instruction at "0x1ca12b95" referenced memory at "0x00000000". The memory could not be "read". Click on OK to terminate the program. Clicking on OK doesn't terminate labview but the NIMax.exe process gets closed. Do I need this or what? The program runs fine without it so I'm not sure what is going on.
×
×
  • Create New...

Important Information

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