Yamaeda
-
Posts
10 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Yamaeda
-
-
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
-
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
SlimDX DX11
in LabVIEW General
Posted
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