Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation


About souske

  • Rank
  • Birthday 07/04/1982

Profile Information

  • Gender
    Not Telling

LabVIEW Information

  • Version
    LabVIEW 8.6
  • Since
  1. Hi all, I am trying to set up communication between Met\Cal (Fluke's Metrology Softwre) and LabView. I've noticed that Met\Cal 7.2 has support for NI-VISA driver. I tried to use it but I can't force Met\Cal to use "TCPIP::<port>::SOCKET" syntax, instead it tries to connect to "TCPIP::" and generates an error. Has anyone used this, or know how to set up TCPIP connection with Met\Cal? Regards souske
  2. QUOTE (crelf @ Apr 10 2008, 04:54 PM) That's what I was planning to do. The thing is that right now I'm testing several different options and want to choose the best one for the system I am creating. I can see that with cRIO one has many possibilities to group the code according to its time priority. Not only by using loops with different priorities on the RT part but also by using the FPGA. QUOTE (JFM @ Apr 14 2008, 08:35 AM) If you enable us support on the cRIO you can probably get closer to the 1ms target, by using the RT specific "Wait until next multiple" with 1000us as input.
  3. Too much time with Windows, and I totally forgot that TimedLoops were made for RT targets. With TimedLoop on cRIO I also get nice 1.01 ms, but even cRIO can't squeeze 1ms from a standard "while" (with RT version of "wait until..." ). Thanks for the reminder!
  4. Hello, I'm trying to get loop speed and I've got result that I have not expected. I set "wait until next ms multiple" to values from 10ms to 0 ms and I want to check how fast the loop runs. Can anyone explain why when I set 1ms I get 2ms? Is there something wrong with the vi structure? I attach vi that I use (created in LV8.2). Download File:post-1959-1207817923.vi
  5. Is it possible to configure FPGA Compile Server in such a way that it would omit the tests at the end of the compiling process? Regards souske
  6. QUOTE(Yen @ Feb 20 2008, 07:35 PM) Yes the are available and they "should work on QNX" (NI words). Setting the Period in the Timed Loop works (it is easy to see that), but I don't know how to check if the loops are actually executed with the set priorities. Is there any difference between 0 ms wait and not using wait at all?
  7. Thanks for the clues. The error number I get is 248, which seems not to be described anywhere. I found a flag that does not change the time itself but allows reuse of the port without waiting. Well setting it doesn't help, but I'm still digging Any ideas on the error?
  8. Is anyone planning to visit the Embedded-World conference in N├╝rnberg?
  9. Hi I'm trying to run double loop program. One while loop acquires data the other transfers it via tcp/ip. Both loops are closed in a Flat Sequence Structure. Before the the sequence I put TCP Listen and set the timeout to -1 (forever). After the FSS I close the TCP connection. In client that receives the data I open the connection, while loop where I get the data and closing connection after. It happens that the Listen doesn't wait for the incomming connection. From the observations I see that the source of the problem might be not properly closed connection, because if I wait a moment I
  10. QUOTE(eaolson @ Feb 19 2008, 11:27 PM) Well maybe not so moot Eventhough its QNX, when I run a loop similar to yours (without wait until next ms multiple) I get average execution time around 0.5ms. Which as you can see is not useful information if I want to set the frequency for the loop. And the puzzling fact is that when I checked exactly what the times of specific cycles are, they ranged from 0 to 3 ms. So it looks like in reality you actually take the largest value instead of an average.
  11. Well then I deeply apologize for not specyfying that all those tests are executed on QNX RTOS How do my assumptions and results look like now ?
  12. Hi I was trying to determine at what maximum frequency I can run my for loop. To do that I set the "wait until next ms multiple" to some value and then calculated the time it actually took the loop to execute and then compared them. If they mached I assumed that the loop executed all comands inside without a problem. I went from 6 ms to 1 ms and I got sth like this: wait node time [ms] - calculated time [ms] 6 - 6.00 5 - 5.00 4 - 4.00 3 - 3.00 2 - 4.00 1 - 3.00 I suppose I can safely assume that 3ms is the minimal value I can use here. Question 1. What exactly happens at 2ms that
  13. Now that is really strange. Maybe mondays are not that bad. Today the inline C nodes ARE supported I really don't understand how is that possible, but I'm not going to agrue. After including .o file (in console application properties) C code works like a miracle and there problem with profibus drivers is no more -- souske
  14. Well I found the "C inline node" but this one is also "Not supported by current target". This structure is visible in functions palette only if you writing software for a target that supports it so It took me some time to even find it, because if you're in qnx (or even blank vi without a project) it won't be there and you won't be able to find it using search option. I don't know if it's a problem of a trial version of my MicroSDK or is it just THAT limited? I find it hard to believe especially when you mention that NI treats CIN as a legacy. I'll keep on hitting that wall -- souske
  15. Thanks for the reply. As I wrote I'm using LabView Embedded Developmnet Module with some add-on that I found on ni.com that allows me to cross compile for QNX. The standard C code node (I assume you mean Code Interface Node) is not supported by QNX target, at least that's what the error says: "Code Interface Node: Node not supported in current target". Right now I'm trying to use Call Library Function Node. I compiled the windows dll example for qnx (I used QNX Momentics) but I still get some linking errors when I try to build it the project in LV: C:\tmpo\sysexec\QNX_Console\QNX_Applic
  • Create New...

Important Information

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