hooovahh

51 minutes ago, carl078 said:

Is it possibile that I can't see the NI CAN library examples because in MAX I have only 64bit Labview Runtime? 

 

Probably. Again NI-CAN drivers, which you need to use your 8473, only work on LabVIEW 32 bit.  Do you have LabVIEW 32 bit installed? Do you have the NI-CAN drivers installed? Do you see the "CAN" palette under Measurement IO?  If not then you need to resolve this.  Sorry.

2 hours ago, carl078 said:

I already installed these drivers. Can't I use the XNET examples if I install the NI-XNET Compatibility Library for NI-CAN? Installing the NI-XNET Compatibility Library for NI-CAN - NI

No you can't.  This lets you use XNet hardware (which I don't think you have) but use the older NI-CAN drivers.  This was intended to help developers transition to the newer XNet hardware but use their old software.  You cannot use any XNet sessions on the 8473 hardware. 

I can't open it at the moment it is new too of a version.  But based on the name it looks like it is again using the XNet drivers not the NI-CAN.  You need these drivers for the USB-8473.

I'd need to see some code.  For NI-CAN I usually start with the example provided by NI. Get that working first.

Oh I'm sorry I did a quick google search and of course the first search result shows a picture of an XNet device but when you click on it it shows the correct one.  Well in that case you need to use the NI-CAN drivers which also appear on the Measurement IO palette.  Note that you can't do the Signal API in NI-CAN with that hardware and can only use Frame API.  But that's okay my conversion library returns frames.  Part 3 of the CAN blog also goes over NI-CAN hardware.  And again there are examples in the Help >> Find Examples.  NI-CAN hardware is old and not getting updates.  It also is only 32 bit binaries so it only works in LabVIEW 32 bit, but can run on 64 bit OSs.

With the XNet drivers installed there will be a new palette under the Measurement I/O for XNet functions. Also in the Help >> Find Examples there are several thing showing how to read and write frames on the hardware.  Additionally I have two CAN blogs that might help out with Part 3 talking about XNet code for doing basic frame functions, and Part 6 which talks about the different XNet session types.  But also if you are just dealing with CAN signals, and not frames you don't need my conversion library to work with XNet hardware.  You can create the signal sessions and do the writing as single point session types which the hardware will then retransmit at the rate defined in the database.  My conversion library is primarily used for situations when you don't have a Signal API and just have the raw frames. 

Glad you got it working.  In the future you can get the packages from a computer that is online and copy them to the other.  These are usually found in the folder here:

C:\ProgramData\JKI\VIPM\cache

Finding all dependencies from that can be a pain.  Oh and VIPM has a Package Configuration feature that lets you pick a set of packages, then save it as a configuration, and even store the package files in a single file.  This VIPC file can be copied over to the offline PC and installed through VIPM without the internet. This used to be a premium feature but I think it is include with the community edition now.

45 minutes ago, carl078 said:

Using the hooovahh's wrapped library is it possibile to:

1) load a specific .dbc file

2) write a float value in the data payload

3) display the CAN BUS frame just before trasmitting it

Yes this is the purpose of the Frame Signal conversion library. Development and discussion has primarily been taking place over on the dark side here. A more polished (but older) version can be found on my CAN blog here.  

24 minutes ago, Rolf Kalbermatter said:

We are also developers, not just whiners! 😀

I wasn't suggesting you were whiners.  If I ask for support from NI I don't think that makes me a whiner.  I was suggesting the changes you are proposing are useful for everyone, and that if you have useful changes, all VIPM users can benefit from them by having JKI use what you've developed.  Because you are a developer.  I also asked that question because I wanted to know incite into why VIPM does what it does so I can be a better developer.

Has anyone talked to JKI about this? I'm sure they make VIPM do this during the build for a reason and they would probably be interested in the changes you are doing.

Quote

 There are other edge-case issues too, that cannot be resolved just by renaming.

Like what? Are you referring to the earlier discussion, where you may have "32" in the DLL name when it is a 64-bit binary?  I handle that by only performing the rename if there exists the correctly named DLL for the other bitness, on disk. Otherwise it leaves it.  User32.dll wouldn't be renamed for multiple reasons. But even if we installed "MyAgeIs32.DLL" it wouldn't rename it unless there exists a "MyAgeIs64.DLL" and we are in 64 bit LabVIEW.  Not perfect but I'd prefer that over editing the VIPM build environment.

On 11/29/2024 at 4:34 AM, ShaunR said:

I think we are talking past each other.

I don't have a problem with naming. That is just what the *.* stuff does. I'm interested in what Rolf is doing to put the *.* into the node paths. I have a problem with linking-the VI search popping up during installation, VIPM not compiling everything and asking the user to save after use. This is caused by VIPM setting in concrete, the full DLL path in the nodes when it builds and not compiling certain VI's after installation.

Yes the *.* stuff would take care of a lot of this.  But it seems VIPM does weird things to path during the build.  That's why I did the post install renaming work. VIPM has the linking to a full path to the DLL, so renaming that linked path on install seemed like an easy way to make it work the way I wanted.  A post install fixing the paths work as well, and in fact Jim posted a VI that can fix the paths on post install.  My issue with this is it is time consuming for the post install to open a reference to every VI, find all call library nodes on the VI, and then update the path on them, and then save the VI.  Especially if you are installing a ton of VIs.  Renaming the DLL is much fasters.

On 11/26/2024 at 3:57 AM, ShaunR said:

It's not a problem I have. I name them x32 and x64, if necessary, so there is no issue with the likes of user32.dll.

I'm also in Windows only land, and renaming the DLLs in a Post Install has worked well enough so far.  If we in a 64 bit LabVIEW for instance the post install looks for if there are DLLs named [X].dll but there exists an [X]64.dll.  If so it will delete the [X].dll and rename [X]64.dll to [X].dll.  This renaming bit also works in reverse looking for [X]32.dll if we are on a 32 bit version of LabVIEW.  Development then is done in one bitness statically picking the correct DLL. I have no clue how difficult or complicated this gets supporting Linux.

We bought a new perpetual license of LabVIEW for our VIA a few months ago.  It worked just like the old one.  I was able to add it to the VLA software, then create disconnected licenses for my users, or machines. The discount offered was frankly way more than we were expecting.  It wasn't in the budget this year, but my manager was able to push it through. When this year is up, we will look into if it makes financial sense to purchase another year or not. I think we skipped 3 years of software buying, so upper management was happy to have saved those years in software cost, and am grateful we didn't take NI up on their offer to get a locked in price for 3 years on the subscription model.

Oh and as for Windows 11, it doesn't have to be all bad.  We have a set of software that gets installed on a base Windows 11 that uses OpenShell to bring the start menu back, ExplorerPatcher, and a couple WinAero Tweaker settings to do things like have the normal context menu, bring paint back, set remote desktop, and various other things people are used to. None of my users so far have realized it isn't Windows 10.  These tweaks shouldn't be necessary, but at least there is options to make it better.

People will decorate their office with retro software boxes, and game boxes. So yes various LabVIEW manuals, books, and old software gets you a bit of nerd cred. I have a box of Windows 3.1 on my shelf next to my copy of LabVIEW for everyone, LabVIEW 7.0, and my bound thesis.

Writing strings to TDMS that are a byte stream can be tricky.  I have a Read/Write Cluster to TDMS and it flattens it to a string.  But as you noticed there needs to be special consideration for null.  Well it also turns out that on different platforms there are other characters that need special attention too. You can absolutely do extra work on your images.  But I fear that you won't get the performance you want. TDMS is crazy fast and all, but it sounds like a bonkers amount of data real fast, and I don't know if it will be able to keep up, especially if there is special code needed to convert a string ready to be written to TDMS so the null (and any other characters you want) get written correctly.

Writing an array of bytes also sounds crazy for this application. The number of samples on the channels might approach NI's limitations for the data type, and then keeping track of where the offsets are for files would need to be a separate channel.  I've done stuff like this for logging raw CAN frames to TDMS files but that seems like way less data. Honestly you might be better served writing to binary files, then having the TDMS file just keep an index of the file names or locations for replay.  Not sure how I'd go about solving this.

Thank you for your continued reports. If it continues to be a problem Michael will twist various knobs behind the scenes.

One other odd side effect is I've seen several reports that are clearly bots, that think it is a reply system. The report will be a normal spam message but reporting some content. So at least those ones only I need to deal with and you won't see.  Sorry again about all this.  I have talked to the site admin again emphasizing the severity, and frequency.

Oh sorry I didn't read your post closely enough. I don't know how to do that.

I think what you want is MoveBlock. This is basically a function that takes a pointer and returns the actual data at the pointer. I don't deal with DLL calling often, and I have a hard time figuring out things so I might be wrong.  You may want to do some research into it.  Here are a few links.

4 hours ago, Mads said:

I agree, with the former😉 It is time to pause the planning to redecorate the kitchen when there is a fire in the living room (no matter how fire retardent the new paint is going to be).

We are at the whim of the city planners to approve of the use of the fire extinguisher...okay the analogy falls apart a bit there.

I do occasionally have correspondence with him. He is aware of the spam issue and we've talked about turning on content approval. He seems to want to update the forums and just has limited bandwidth to do so. Until that happens I'll just keep cleaning up the spam that gets through.

1 hour ago, Novgorod said:

Of course you're right, it should be sufficient in almost all use cases to simply use the provided vi.lib version. It's more a curiosity thing and also a neat trick to have very compact portable tools. For example, the built-in zip/deflate/inflate functions eliminate the need for external dlls, since (to my knowledge) there is no pure G code zip implementation, but that's a story for another thread.

I did try to implement inflate/deflate in pure G.  There was a website that explained in pretty easy to understand english how the compression works, and gave example code on how to implement it.  I went through it step by step but it still wasn't producing the correct data.  After trying in my free time for a bit I gave up. I thought it would be helpful on Linux RT for web server stuff where it could make PNG compressed images. There are alternatives.