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

Attached is one way to do it with the method I described. It should get you on the right track, but let me know if I missed the mark here.

Download File:post-3266-1140498851.vi

Cheers!

Joe (orko)

. I didn't know you could wire a string to the resource name terminal of the serial open subvi. :worship:

Can't you use the Measurement & Automation Explorer to set these?

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!

The VISA resource name (taken off of the reference output of an Visa Open primative) can be wired to a Instrument property node that gives you all kinds of information about the devices. One of these properties is the Interface Information:Interface Description property which will spit out things like "ASRL1 (COM1 - Communications Port)" or "ASRL10 (LPT1 - ECP Printer Port)" which can be parsed easily for COM1 or LPT1.

If you wire a "VISA Find Resource" with a search query like "ASRL?*INSTR" and wire the output array to a FOR loop, you can iterate through them getting those human read-able names.

Of course, that may not be the easiest way, but it seems to be the least dependant on machine specific things such as aliases.

YMMV,

Joe (orko)

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.

Sorry about that, here it is in 7.1. In my opinion there is nothing wrong with a subVI that reads in a config file and parses it to build a big bundle by name cluster to pass out. 40 elements in a cluster is not bad, you start taking performance hits with an array of clusters or even worse, an array of clusters with an array as one of the elements of the cluster.

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

I think I understan what you are asking, see attached VI. Create a constant on the middle node of the bundle by name, add what ever data tpes you want to the constant and lable them. Than wire what ever data you want into the cluster elements. I think maybe the problem is you are used to defining the name of your cluster elements by wireing a control to the elements and letting the cluster element name take on that of the control lable.

<-- 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: .

Is there some reason why you cannot use an array for so many items of the same type? With that many I just have to suspect that you could squeeze out some more program efficiency as well as wiring / coding style efficiency using arrays.

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...

Isn't what you're after just a functional global? The whole idea of having a local is to access FP objects...

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?

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.

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

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

Just discovered that if you take any decoration and stretch it. It will only allow you to stretch it to a size of 4095x4095 pixels. This is is LV7.11. This is not a show stopper but was curious why?

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.

Hopefully you're wrong on both accounts, but thats very forgiveable! It is actually probably your first medium sized application and if you keep working with LabVIEW it surely should not be your best. It is amazing how one's definition of "large application" and "best coding practices" change with experience. The first time I was involved in a LabVIEW app that exceeded 1000 VIs I thought we'd coded the biggest thing in the world. Then I found out about one that exceeded 8000...

Perhaps I shouldn't tell you this, but there are actually about a half a dozen ways to move data between loops, so just file that datum away for now and concentrate on the event stuff Michael Aivaliotis pointed you too and the gueues PJM expounded on. Queues remain my favorite.

Amen to that. A pretty reasonable way to look at the Event Structure is that it is an interrupt handler, software interrupts rather than hardware. No, it's not exactly that, but the analogy holds. An Interrupt Handler, properly used always does the absolute minimum with the data and takes as little time as possible. It catches the interrupt, verifies what type, performs any _must do_ data massaging and then passes the work off to another routine, usually queued, and goes back to watching for the next interrupt.

Go, and do thou likewise ...

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 .

It is usually a good practice not do any work in the event structure. Event structure are used to catch events and then through some mechanism, the job to do in response to that event is selected.

The major advantages is that instead of beeing tightly coupled to the event, the job to do can be very easily recalled by anything at anytime.

In the image below the job is passed to the case structure through a shift register. You could also use a queue to pass job and data to another loop.

You might want to investigate queue, as you will see they are a lot more efficient to pass data between parrallel loop than locals.

PJM

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!

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

There is a file here:

C:\VXIPNP\WinNT\NIvisa\visaconf.ini

That file has a bunch of comments and allows you to comment out unused interfaces. That may solve your problem.

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

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?

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.