Jump to content

Rolf Kalbermatter

Members
  • Content Count

    3,053
  • Joined

  • Last visited

  • Days Won

    153

Everything posted by Rolf Kalbermatter

  1. I've been looking at the GCentral site and visited the Package Index page. While I find it a good initiative I see here the same problem that makes me loath browsing the NI site for products. I'm interested in the list of packages mostly yet half of the screen is used up by the GCentral logo and lots and lots of whitespace. I may be a dynosaur in terms of modern computer technology and not understand the finesse of modern web user interface design, but a site like that simply does not make me want to use it! Maybe this design will be beneficial to me in 10 years from now when my eyesight
  2. For what I and our company does it seems to be more than adequate, but then we don't focus on shiny web applications which sport the latest craze that changes every other year. We build test and manufacturing system where the UI is just a means to control the complex system not the means to its own end. In fact shiny, flashy user interfaces rather distract the operator from what he is meant to do so they are usually very sober and simple. For this the LabVIEW widgets are mostly more than enough and the way of creating a graphical user interface that simple works is still mostly unmatched in an
  3. The problem is that NI seems to get out of a lot of hardware in recent years. Most Vision hardware has been discontinued or at least abandoned (no new products released and technical support on the still sold products is definitely sub-par compared to what it used to be in the past). NI Motion is completely discontinued (which is a smaller loss as it had its problems and NI never was fully commited to compete against companies like MKS/Newport and similar in that area). NI DAQ hasn't the same focus it used to have. NI clearly has set its targets on other areas and for some part moved on f
  4. Not out of the box. 32 bit LabVIEW interfaces to 32 bit Python. So you would need to have some 32 bit Python to 64 bit Tensor Flow remoting interface. If 64 bit LabVIEW is a requirement the lowest possible version is 2009 on Windows and around 2014 on the Mac and Linux platforms.
  5. If you want to take the Python route then of course. As far as the Call Library Node is concerned there is virtually no difference since at least LabVIEW 2009 and even before that the only real difference from 8.0 on onwards to 2009 is the automatic support for 32bit and 64 bit DLL interfacing at least if it is about pointers being passed directly as parameters. Once you deal with pointers inside structures you have to either create a wrapper DLL anyhow or deal with conditional code compilation on the LabVIEW diagram for the different bitnesses.
  6. NXG is Windows only anyhow. Sure NI says that they have been keeping options open for other platforms with NXG and to some extend that must be true because they need to be able to keep building executables for at least the NI Linux RT targets, but I would say it is a safe bet that the significantly longer than expected development time of LabVIEW NXG is not caused mainly by these attempts on maintaining full multiplatform support but that there have most probably rather been decisions to take shortcuts that make a mulitplatform version mostly unfeasable. NI's bet is maybe that .Net Core will e
  7. Actually unixODB does exist but it's not trivial to find drivers for some database systems that will work for your unixODBC version. The Microsoft SQL Server drivers for unixODBC require a very specific version of unixODBC to work with. The bigger problem however is that pretty much all database access libraries that exist for LabVIEW do this either through the ADO/DAO Active X interface or the .Net Database API which in turn internally interfaces to ODBC for the drivers that are not native ADO/DAO or .Net. Both Active X and .Net are not available in LabVIEW on non-Windows systems. So all
  8. Linux ODBC or iODBC or unixODBC work in principle. The idea is not bad but hampered by the fact that you need a compiled version of a database ODBC driver for your platform. As that is not generally something all database providers are eager to do, it makes unixODBC less interesting overall. In cases where you have a native driver like FreeTDS I would usually consider that preferable to trying to get unixODBC to work. unixODBC is an extra complication on top of a driver and the ODBC manager implementation is pretty complex in order to provide version compatibility between both higher and
  9. The SQL Server protocol has been reverse engineered as it is based on the old Sybase Tabular Data Stream format that Sybase did document at some point in a public document. Microsoft licensed the Sybase code and eventually created the SQL Server product from that. The underlaying network protocol is still very much the original TDS format with some extra features sprinkled into it by Microsoft over the years. This is the MS document from the original Sybase 4.2 version of the TDS documentation. This is a more detailed documentation about the later Microsoft modifications to the proto
  10. That's most likely heavily influenced by the fact that the original Concept VI image analysis library, which they acquired from Graftec I believe, had to create some sort of handle like object without the ability to hack into LabVIEW itself. Their solution was to create a cluster with an image name string and some extra attributes including the actual pointer. They made the cluster such that only the string was visible. To a casual user it looked like it was just the name of the image but internally it consisted of a lot more. The name was used to register each handle in an internal list and e
  11. The difficulty is that it goes beyond the by value dataflow principle in LabVIEW. And there is no easy way to fix that. The reference nature for images is neccessary as otherwise you run out of memory very quickly when trying to process huge images. But it remains a strange duck in LabVIEW land and even I have sometimes to remind myself that IMAQ images work differently than standard LabVIEW data. You would think that the DVR might change that a little as it is in fact a similar concept but there you need a special node to access the internal data and that protects from most possible race cond
  12. It's a named reference. You could think of it as a name and a pointer. There is an inherent mapping in it similar to other named references like VISA or DAQmx refnums. If you pass in a string, LabVIEW converts it automatically to a refnum by looking up the name in its internal registry for that refnum class. If you pass in a refnum whose internal "pointer" is a valid reference it will directly use that reference instead and save the intrinsic lookup in the refnum registry for the according class. (Class being here a refnum class not a LabVIEW class).
  13. From the hardware manufacturer. They are responsible to support their product. Given their questionable license practice they may be out of business already or it could happen anytime in the future or they decided that the market wasn't good enough to pay for real development expenses and stopped supporting the product. Whatever, if they can't help you nobody else can. Developing such a product is for sure a serious investment but every company sooner or later learns that maintaining and supporting such a product in the long term costs even more in terms of resources and that is where thi
  14. A Samsung EVO 960 has a maximum transfer speed of 1.5GB/s and that assumes that it uses NVE rather than SATA. With an EVO 970 you get close to 2GB/s. This are ideal rates and require that the PCI bus controller and disk have an optimal connection and the PCI bus controller has near perfect chipset drivers. The reality is generally somewhat below that and the software bindings inside user space are usually even less performant. Old SATA based SSDs max out at around 500MB/s and that is bus imposed. There is no way to go above that with SATA. The FPGA DMA tech is pretty impressive but I woul
  15. The comment about being able to choose more than one selection is not true since it is a radio button list that resets any previous selection when you select something new. For me I selected my own (company framework) which can sometimes vary since there are customers who use their own framework too. But I also have used DCAF and similar systems which had a CVT backend for most of the data handling.
  16. I'm afraid the chance for that is very small. Maintaining a separate install is a lot of work and the Community Edition is a different installation than the standard LabVIEW installer. More importantly: There is no license manager for the Linux version. So there is no way to put up something like the yearly renewal request for activation of the Community Edition. Basically it would be way to easy to distribute the LabVIEW Community Edition for Linux by bad actors and with no way for NI to even know about where it is used. The yearly reactivation requirement for the Community Edition is the onl
  17. Unfortunately it does not show the definition of canfd_frame datatype which seems to be the one that is important here. But there is a chance that this is the actual problem. I would expect the 8 bytes in the cluster in your datatype to be the actual CAN data. In that case your cluster is missing the UINT64 timestamp;//us element and if you pass in a big number of frames as lengh parameter this of course will amount to 8 bytes in the message buffer missing for every message element and that on a total message length that is normally 24 byte! That adds up very quickly and will eve
  18. The LAVA palette itself only installs a Lava icon into the LabVIEW palettes. When you then install Lava libraries (possibly OpenG libraries), they should appear in there.
  19. No that information is generally only available to people outside of NI on a limited "needs to know" base and the decision for that is handled by AEs for simple issues or the product manager for the product in question for more involved issues.
  20. From the look of it I would guess a bug in your zlgcan_wrap.dll or one of the myriads of other DLLs it depends directly or indirectly. Nothing in the LabVIEW diagram looks suspicious from the little information (none) we got from you about this DLL interface! So what is the C declaration of this function and its datatypes and subtypes?
  21. So Microsoft tightened security once more and made Common data files not so common anymore that every user can access them? Good to know.
  22. Ohh well I missed the "snapshot" 😆 But I would have to agree with everything in your post. Matlab isn't going to make this any easier at all. 😆
  23. Are you serious? Do you want to operate those cameras in 320 * 240 pixel mode? First do some basic calculations about data throughput before starting to ask such questions. Your USB bus certainly will start to hick up if you try to transfer that many cameras at full resolution simultaneously to your computer. It's likely to cause trouble even with a lot less of cameras. USB never was intended for so many high speed simultaneous devices and even with GigE ethernet you will be getting trouble if your cameras have even remotely modern resolutions and you want to do more than 1 or two frames
  24. Sounds suspicially llike a padding mistake. I see 38 or 39 plus a multiple of 48 in those numbers.
  25. Vision doesn't require realtime at all. What are you really trying to do here?
×
×
  • Create New...

Important Information

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