Jump to content

JimPanse

Members
  • Content Count

    36
  • Joined

  • Last visited

Everything posted by JimPanse

  1. Hello, experts, I am just taking my first steps with Labview on Linux. For the implementation of various projects I am missing the drivers for Linux as I am used to from Windows or Pharlab. I have heard that Imaq and Vision will come at the end of this year.... all without rifle. Which image processing tool would you recommend for Linux? For Ethercat I have discovered the following : https://openethercatsociety.github.io/doc/soem/index.html Does anyone have any experience with this or are there already Vi`s for Ethercat under Labview Linux? Furthermore I would lik
  2. It is about an image processing where the result is a parameter for a control. Here I need a real-time in the range of 1 ms.
  3. Is it possible to make Windows 10 realtime capable, so that i can use Vision?
  4. I could imagine that RT Linux from a PXI system also works on a PC. This will certainly not be allowed by licensing law.
  5. This means that RT Linux for Desktop PC is theoretically possible. Can I buy a Linzens from RT Linux for Desktop PC´s? And how long will Pharlab ETS be available?
  6. Hello, experts, in the current description of the NI Vision Acquisition Software it says: http://www.ni.com/pdf/manuals/375130k.html Deprecated Features ◾NI - IMAQ 19.0 .... ◾Removed support for LabVIEW Real-Time targets running Phar Lap ETS OS Will the OS Labview Real Time (Phar Lap ETS OS) be discontinued and is there an alternative based on Linux? a good time Jim
  7. Hello, Rolf, thank you for your message. I don't know if I understood it right. The software should be developed under Windows. The program created in this way runs independently on the FPGA and communicates via RT FIFO with RT? If I understood that correctly. Is there an example or a forum post where this is discussed? A nice week start Jim
  8. Similarly I tried to integrate the framegrabber under RT. Since the framegrabber is not found there is no RIO reference. I don't know how this works. A direct image processing is absolutely necessary. And also the data exchange of the results with the fieldbus. The question (which I cannot answer yet) is whether you need an FPGA or can implement it with CUDA. Since I already have experience with FPGA, I chose this solution. I have no experience with CUDA. If I would use CUDA then Windows is mandatory. I don't think CUDA works on RT. The advantage with CUDA would be that you don't
  9. There is currently no 100% definition of the requirements. This is all in a state of flux. Full or Extended Full is required. Power over CL is not mandatory. I need real-time for communication with the 5 most common fieldbus Systems. I didn't understand your suggestion to transfer the FPGA code to the frame grabber under Windows and then use it under RT. How should the communication under Labview Realtime with the frame grabber work if the frame grabber is not recognized under RT?
  10. It can't be that the specification says that the frame grabber is supported and then it doesn't work. I can't afford such a procedure with my products. I could also imagine a different solution approach, e.g. with an additional extension. Make Windows real-time capable. But here I am still at the beginning. Providers who promise this are among others www.intervalzero.com/ https://kithara.com/ www.sybera.de/ …. There are certainly many other providers here. Advantage: The Framegrabber works under Windows. No Labview Realtime would be necessary anymore and the a
  11. Hello, bbean, thank you for your answer. The frame grabbers PCIe 1477 and PCIe 1473r work under my Windows System. I had the frame grabber PCIe 1473r on loan from NI and can't test it under Labview Realtieme anymore. The frame grabber PCIe 1477 does not work with Labview Realtime on my System. According to the specification: http://download.ni.com/support/softlib//vision/Vision Acquisition Software/18.5/readme_VAS.html NI-IMAQ I/O is driver software for controlling reconfigurable input/output (RIO) on image acquisition devices and real-time targets. The
  12. Hello, experts, it's a shame that nobody has had any practical experience with the frame grabber under LabVIEW REaltime (Phalab). The documentation contains the following, among other Things: http://download.ni.com/support/softlib//vision/Vision Acquisition Software/18.5/readme_VAS.html NI-IMAQ I/O is driver software for controlling reconfigurable input/output (RIO) on image acquisition devices and real-time targets. The following hardware is supported by NI-IMAQ I/O: ....... NI PCIe-1473R NI PCIe-1473R-LX110 NI PCIe-1477 This means that the f
  13. Does anyone have an idea what you need for the framegrabber to work under LabVIEW Realtime? Has anyone ever made one of the two framegrabbers work under LabVIEW Realtime? Greetings, Jim
  14. The FPGA tool is also available. The frame grabber runs on the same PC under Windows 7 (other hard disk). Does anyone have an idea why the frame grabber is not recognized in realtime? a nice weekend Jim
  15. The frame grabber requires the Imaq IO 18.5. According to NI, Vision Acquistion is supported by Labview Realtime (Pharlab). And all the hardware included in it http://www.ni.com/download/ni-vision-acquisition-software-18.5/7840/en/ It would be interesting to find out if anyone was able to integrate the frame grabber (pcie 1473r or pcie 1477) under Pharlab. Then there would be hope then :) a pleasant time Jim
  16. Hello, experts, I am trying to put the frame grabber PCIe 1477 into operation under Labview Realtime (Desktop PC). Unfortunately the card is neither displayed in the MAX nor in the project. As an alternative the frame grabber PCIe 1473r LX110 would be conceivable. Has anyone ever worked with such a frame grabber under Labview Realtime? Or does anyone know what to consider to make the frame grabber work with Labview Realtime ??? Many thanks for the numerous answers Regards, Jim
  17. Hello experts, I've figured out how it works by now. A code on the FPGA side like on the PCe 1473 is no longer necessary. The required VI´s on the host side for the serial communication can be found at: \LabVIEW 2018\examples\Vision-RIO\PCIe-1477\Common\CL Serial NIFlexRIO Merry Christmas Jim
  18. Hello experts, I am interested in the frame grabber PCIe-1477. http://www.ni.com/de-de/support/model.pcie-1477.html Unfortunately, the examples are not complete in my opinion. At first glance I do not have the serial communication for the parameterization of the camera. (Requires: NI Vision Acquisition Software 18.5). Does anyone have experience with the frame grabber and how was the parameterization done? Have a nice Weekend Jim
  19. Thanks for the friendly answer! The FFT calculation does not have to be done every 4 μs. At that point I should have contributed more. It is a 250 kHz continuous detector and this processing must be guaranteed. It would be quite conceivable to store a certain amount of data and then parallel to processing. For example ... So if an FFT calculation takes 100 μs, you could cache 25 measurements and calculate them in parallel. If that would be feasible .... The question arises, which low-cost FPGA is able to store the data between and calculate it in parallel? Simulation can determine
  20. Hello experts .... Thank you for your answers. The FPS are really 250 kHz @2048 Pixel GPU So a current graphics card e.g. 6GB Asus GeForce GTX 1060 Dual OC Active PCIe 3.0 x16 (Retail) should have a transfer rate of 15 Gbytes / s. This year PCIe 4.0 will come out with twice the data rate. At an expected data rate of about 1 Gbyte / s that should not be the bottleneck, right? So theoretically it should work with CUDA. What should be the limiting element in data transmission? In the USB3.0 variant, the USB3.0 interface is the data bottle neck. This should max. 640Mbyte
  21. Hello and thank you for your answers. Then an FFT of a line with 2048 pixels and corresponding parallelization in 4μs would be possible. As far as I know, the mentioned NI FPGAs run at 400 MHz. The question that arises is which type of FPGA is suitable? Because he has a decisive influence on the costs. According to NI, the FFT runs in 4 μs (2048 pixels, 12bit) with the PXIe 7965 (Virtex-5 SX95T). The card unfortunately costs 10,000 € and would probably blow up the project. Therefore, I would like to know if it also with the variants: Kintex-7 160T / IC-3120 (USB3) Virtex-5
  22. Hello experts, I have a camera application (USB3 or camera link) and would like to do an FFT analysis of a line with 1024 or 2048 pixels. Data type U8, U16, I16. The processing must be very fast due to the process. The processing time should not take longer than 4μs. It would be conceivable to process with an FPGA, e.g. Kintex-7 160T / IC-3120 (USB3) Virtex-5 LX50 / PCIe 1473 (camera link) or on the GPU using CUDA. I also heard that Labview 64 bit FPGA should be much faster. Does anyone know if the processing time of 4 μs is possible with the describe
  23. Hello Rolf, thanks for the expanded view. If I configure a desktop PC with a Pharlab Labview RT system I need the appropriate license. NI also has to pay for this eventually. These costs should not be incurred in Linux. Licensing costs for example, DAQ should not apply also. These costs should be compared with the hardware procurement. Therefore, some applications would be implemented with a desktop Linux NI RT system. Or did I miss something? A pleasant start to the week, Jim
  24. Hi Experts, there is a guide, experience or an image with which you can configure a desktop PC to a Linux NI RT? a pleasant week, Jim
  25. Hi Experts, has someone brought the NI Linux RT kernel with a desktop PC to work? Similar to the PharLab operating system. Or is there a how to create the NI Linux RT operating system itself? Otherwise, I would be very interested in a working group that developed the NI Linux RT operating System for Desktop PC´s. a pleasant start to the week Jim
×
×
  • Create New...

Important Information

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