Yamaeda

I have no serious plan on making a DX11 game or similar, although it'd be really interesting and the multithreading part is alot easier than in e.g. C++. So, performance isn't a real issue for now, but if i get this to work i'll see if i can get direct compute to work from within LV. /Y

Hi guys! So, for fun i'm trying to follow a C# tutorial on DX11 and get it running in LabVIEW through SlimDX. As far as i can see i've done all the steps necessary, but i only get a window, it doesn't clear to the expected color. Have any of you tested this? What am i missing? The tutorials i've looked at are linked in the VI. And those .net nodes sure makes the code BIG. (If i get this to work i'll probably make some wrappers to clean it up) /Y tutorialDX11-2013.vi

Do you have "Allow debugging" active on your VI's? That's something that's always disabled in a compiled EXE and would explain the difference. /Y

Unless i misunderstand you could do it with a simple Build array. Just expand it to 3 inputs. /Y

System Exec, as mentioned, can only perform 1 command (a batch file is 1 command), but you're only really performing 1 command. You perform 1 attrib command depending on machine name. I'd recommend checking the name and parameters in LV and just send 1 system exec as needed (unless LV advanced file functions can change the attributes, haven't checked that). Then no batch file is needed. /Y

Now i've had time to return and try some more on this issue. Changing the DLL calls to Reentrant and then changing the VI execution thread made alot of difference! I haven't actually tried it coupled with the mentioned ActiveX, but i got similar problems in another program that uses several parallell processess instead. In this one the Open VI-node caused the DLL calls to generate errror 7005 (timeout). The mentioned changes (some 6 dll calls and vi's preferred thread of execution) has solved it beatufully! Thanks alot Rolf! (cant mark as solved or something on this forum, can you?) /Y

I must say neither of your solution really tickle my "oh i must program that"-nerve. I was hoping for just setting the dll call to "any thread" and keep the VI as non-reentrant to protect it but allow it in another thread than the UI one. I checked today, and they are all set to UI thread currently. The drivers are quite old, probably from LV5 or something originally so the multithreading probably wasn't in the design. A coworker actually did the 2 application test today and it worked well. I dont think any of us has done inter-application solutions before though, so that solution has some hurdles but might be a good solution. I'll have to dig deeper into the different solutions. /Y

Hmm, interesting idea, i'll have to look into the Call Library configuration of the drivers. However, shouldn't the multitasking force the 2nd loop to run more often? Any other idea of a possible fix/workaround? /Y

I've also wrapped the activeX in a VI of it's own and set it to another thread, same with the dll-vi's. The main difference is that i dont get timeouts any longer (as it seems to have broken into the dll sub-vi's). Yes, somehow they must work in the same thread (probably UI), but it feels very strange, to say the least. /Y

Hiya! I've got a vi which has 2 loops. Loop1: vi's with dll based IO through a dedicated PCI card. Loop2: ActiveX-based com through RS232. ActiveX is quite slow, about 200ms/call, but that's not the issue (although annoying). I check status by polling through 5 activeX calls, thus 1 sec. The Loop1 easily loops at 3ms if needed, i run it at 30. Lots of time to spare. That is, until i start the 2nd loop. Suddenly Loop 1 runs at 1 sec also and the only explanation i can think of is that ActiveX locks my VI/labview somehow. If i add some small waits between the activex calls loop1 runs a few loops at full speed, then a 200ms loop (the activex time). Anyone has any idea of how to get around it? (labview 8.2) /Y