Jump to content

JimPanse

Members
  • Posts

    49
  • Joined

  • Last visited

Posts posted by JimPanse

  1. Hello experts,

    I would like to use the two functions:

    int clSerialInit(unsigned long SerialIndex, void** SerialRefPtr);
    int clSerialClose(void* SerialRef);

    Execute via a Call Library Function Node.

    I have chosen the parameterisation shown. But it does not seem to work. The function prototype does not seem to be correct either.

    image.png.1e8c062c9b77334f609c941f47f7fa18.png

    image.png.0dddd3fcf0671553cfc85e000fdab778.png


    Can someone tell me how to parameterise the call library function Node in order to execute the two functions?

    Have a good time, Jim

     

     

  2. I haven't yet found the "egg-cellent" in the area of real-time, vision and automation. A few years ago, I thought Labview RT based on Phar Lab was it. There is no RT Linux Labview for Desktop PCs. From my current point of view, a modified RT Linux is a possibility to realise these requirements. And I need the variety of hardware solutions that a desktop PC offers. The NI hardware is too limited and does not offer many possibilities. And with the NI software solutions, you don't know how long they will be supported. In your opinion, which development environment is best suited for such applications?

     

     

  3. It's almost easier to say goodbye to Phar Lab and Labview Realtime and go for Linux RT (preempt_rt). The current RT Vision project will now run under Linux RT (preempt_rt).  Does anyone have any idea what the roadmap of Labview for Linux is? 1-2 years ago an NI employee told me that an Imaq driver for Linux should be released in the near future. Nothing has happened yet either. Therefore, I have now switched from the expensive NI PCIe 1433 cards to EURESYS GRABLINK.

  4. Quote

     

    This device (purchased part) has only one USB connection which was realised with FTDI. There is no other interface on it. I don't think there is a Pharm Lab FTDI driver. Therefore, the question is, is there an RS232 to USB (FTDI) adapter with which the communication could work?  Phar Lab can use RS232. Or is the approach just wrong?

  5. It is a desktop PC running Phar Lab on it.

     

    I assume that there is no driver for USB FTDI converter under Phar Lab. Maybe I am wrong about this.

    So I thought I could use a RS232-USB converter (if there is such a converter) which then communicates with the USB-RS232 (FTDI) converter. RS232 communication works under Phar Lab.  

     

  6. Hello experts,


    I would like to communicate via Phar Lab with a USB device that uses an FTDI chip. Is this easily possible?

    Is there a RS232 to USB converter that can be used under Pharlab? A converter for a converter :)

    I would be very grateful for any suggestions.


    Greetings, Jim

  7. so, if you look at the share price.

    https://www.nasdaq.com/de/market-activity/stocks/nati

    you can see a nice separation there. until 2016, ni was reasonably solid and had a slow steady growth. in 2016 they decided to make everything more efficient and lived at the expense of their customers. at some point the customer notices the reduced performance and looks for an alternative. which is reflected in a share price decline since 2018..... a bold summary... this roughly reflects the correlation of the share price with my personal experience with ni.

     

  8. I found the strategy of approx. 10-15 years better for my needs. if you continue to operate the current strategy like this, then I won't give labview much longer. that is the view from my field of application.... that might be enough for me until retirement.
    i would be interested to know how high the profit per employee of ni was 10-15 years ago and how it is now. then you could estimate whether it is a successful course or whether it is going down.  

     

  9. I also think that it is the strategic staff that is leading labview in the wrong direction. the concept of labview is certainly unique and has its justification. the strategic decisions are simply the wrong ones. the management should be fired and a few innovative engineers should be left to make the decisions. there are enough new technologies waiting to be implemented with labview.

    • Haha 1
  10. Every now and then a small improvement comes along. a real innovation was the leap from version 7x to 8x. I think fpga is not bad either, but it is actually too expensive and there is no real support for it either. I work a lot with realtime and vision and I have to say that nothing has happened since usb3 vision. where, for example, are the coax press frame grabbers?  also that pharlab was discontinued without an alternative for desktop pc's. that's why i switched to labview linux and built the realtime system myself under linux. and if you ever need support for labview linux you're really on your own. in my eyes they've been milking the cow for the last 10 years... at some point even the last drop is sucked out. 10 years ago you called ni and wanted to test a card and 2 days later it was on the table. today you can't even find someone at ni who knows about stuff. NI sBRIO or System on Module was also a good approach.
    but where is the interface to integrate smartphones into labview. or the pi... there are only non-commercial projects like linx.

  11. Hello experts,

    I'd like to make a general assessment. I have been working with Labview for about 20 years and occasionally contact Ni to solve technical problems or to find out about and buy products. I have been observing the trend that service has been getting worse and worse over the years for years now. I have not seen any real new developments in labview over the last 10 years. with the termination of nxg and the associated waste of resources, I have the impression that ni has to save money at every corner to keep the shop running. of course this is at the expense of customer support. i wonder if ni is about to go bankrupt or what is the strategy behind it? slowly i am looking around for alternatives to labview as i can hardly see a future for labview after the current impression. how do you see it...? what is your impression?

    greetings, jim

     

  12. 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 like to use USB3 Vision, Gige Vision and Cameralink under Linux. Are there any recommended drivers for Labview?

    Are there any other drivers, programs etc... for Labview for Linux?


    A good time

    Jim

  13. 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 need the expensive FPGA frame grabber.

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

  15. 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 associated expensive licenses and development extensions.

    What do you think of this solution?

  16. 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 following hardware is supported by NI-IMAQ I/O:

    .......

    • NI PCIe-1473R
    • NI PCIe-1473R-LX110
    • NI PCIe-1477

     

    the frame grabbers should work under Labview Realtime. Do you see it that way?


    The statement of NI (Munich) is now (after the purchase) that the frame grabber PCIe 1477 should not work under Labview Realtime.

    I also had the impression that NI was not really interested in solving the problem. For those, Labview Realtime is an obsolete product.

    The question to NI (Munich) whether the frame grabber PCIe 1473r works under Labview Realtime has not been answered until today.

    Too bad that nobody else made experience with the frame grabbers under Labview Realtime.

    A nice week start

    Jim

  17. 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 frame grabbers NI PCIe-1473R-LX110 ,NI PCIe-1477
    work under LabVIEW Realtime (Pharlab)?

     

    Thank you very much for your help..

    Jim

     

×
×
  • Create New...

Important Information

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