Xnet Compatibility

[Clidia Panahon]

The buffer specified is too small to hold all the data for the read/write function. Solution: determine the size of the buffer from the session and read/write parameters and specify a big enough buffer."

I'm not sure what I'm missing. Any suggestions and/or examples (other than the NI examples, which I've already looked at) would be appreciated. I know it's probably something simple but a solution escapes me right now!

Alrighty then...figured it out. Unlike my previous program using CAN, you have to make sure ALL signals have some value in them. I have "optional" equipment that can be hooked up to the machine that may or not be present. If it is not present, I do not try to read the values from it (via modbus). Therefore, the values are blank. Now I check to see if it is there, if not write zero values to those signals.

Obviously the error message I was receiving had absolutely nothing to do with the problem which is why I was way off course. I guess it was better than the one that states "No one has written an explanation for this error..."

There is an NI-CAN compatibility layer available, but it works the other way around (older NI-CAN application software with new NI-XNET hardware). If you haven't seen it, take a look at this DevZone article. This other article touches on some of the notable performance improvments with the new platform that you can share with your customer...

My team and I are in the process of migrating our application from LV2011 to LV2015. While in this process, we need to be able to make 2015 builds for testing purposes while continuing to build 2011 releases for our current customers. We have a dedicated build PC and I initially wanted to use to build both versions.

The issue is: the version 15.0 of many drivers such as NI-CAN, NI-XNET, NI-VISA doesn't support LV2011. When I installed the version 15.0, the libraries were actually removed from the vi.lib folder of LV2011.

We just moved from LV2011 to LV2015 and basically had the same issues even though we don't have a separate build PC. We solved this by using a virtual machine for LV2011 and working with LV2015 on the host. So no need for a second hardware. Maybe that works for you too.

Theoretically, the shared resources would be upwards compatible such that the 2011 VIs "should" be able to work with the 2015 binary resources (shared system libraries and device drivers). Practically anyone who has written such drivers knows that this is VERY difficult to do and absolutely impossible to guarantee without explicitedly testing it all in every detail.

Now take into account that many of the NI drivers are for multiple platforms (Windows 32-bit and 64-bit, Mac OS X 32-bit and 64-bit, Linux 32-bit and 64-bit, Pharlap ETS, VxWorks, NI Realtime Linux) and NI does provide usually backwards compatibility for the last 3 LabVIEW versions and you see quickly that adding even one more version to this is definitely going to have a huge extra impact in testing. And everytime there is an incompatibility on any of those combinations someone has to go in and make a fix and then testing again all around. If you don't limit the scope there somehow you end up testing, fixing and testing again for unlimited amount of times and no product is released anymore.

I have tried such installations in the past but not for production type development. It was mostly to be able to look at older source code without having to load it into a newer LabVIEW version. Never really executed anything substantial on real hardware. The recommendation about using Virtual Machines is actually the most sensible in this case, aside from having dedicated hardware for each version.

We do the same thing as LogMAN: virtual machines for the older version. Initially the VMs get heavy use, but that tapers off as the older version installations become stable (few, if any, changes or warranty calls) or systems reach end of life. We have systems currently in the field that were built with LabVIEW 7.0, 7.1, 8.0, 8.6, and 2012 (there was much rejoicing when the LabVIEW 4.1 system reached end of life). We are looking to migrate to 2015 after SP1 comes out and will be creating a VM of 2012 when we do so.

I think copying a higher version vi.lib to a lower version device driver installation is almost certainly asking for trouble. While the newer version may use new APIs for enhanced operations, the lower version system driver would not support that. That can cause immediate trouble when loading the VIs as they might attempt to link to non-existing APIs in the old driver, or it may be only later at runtime apparent when certain low level device driver methods are invoked with new extended parameters that it does not support.

So personally if you want to do such an installation chances are bigger that it will work if you install the highest level driver package with support for as many LabVIEW versions as possible and leave the vi.lib on the older LabVIEW versions with the highest supported driver version.

In your example this would most likely mean to install DAQmx 14.0 etc. on the computer to get it install the daqmx and other drivers into the LabVIEW 2011 installation, then rename the LabVIEW 2011 folder temporarily to something else, so that the DAQmx 15.0 installer won't see it anymore and won't remove the DAQmx support from it. This leaves a pretty big change that it will still work after renaming the LabVIEW 2011 folder back after the new drivers have been installed. But as explained earlier I would not recommend that solution for a production quality build system at all as you may end up with obscure errors that are very hard to debug and a bug report to NI won't help much as you work with an unsupported installation.

I am trying to achieve a hardware synchronization between an analog input and a CAN signal. To achieve this, I am using the DAQ device USB-6343 and the CAN Bus device USB-8502. Both devices have the functionality to export/import triggers and clock sources.

Attached you can find my attempt at synchronizing both devices. I am exporting the sample clock trough PFI14 and the start trigger signal trough PFI15 (on the USB-6343). These ports are connected to the USB-8502 T0 and T1 terminals respectively. Both GND are also connected. I am using the 20MHz Time base of the USB-6343, since only that one can be used by both devices (as far as I could tell from the data sheets).

My problem is that when I subtract the time stamps from one another, the difference is equivalent to the difference without any synchronization (around 1ms). Code without synchronization also attached. Am I doing something wrong with the synchronization? Perhaps with the XNET connect terminals VI? Any information would be helpful

The start time, t0 is provided by the host PC when Start VI is called and the values of t0 provided to each device are different during the polling. Thus, the devices are physically synchronized but cosmetically have different timestamps. To correct the time, you can get the actual start time for both DAQmx and XNET, and adjust the start time of XNET as shown below.

However, after trying your code I get this error, saying that the property is not supported. I cannot find any information regarding device compatibility and that property. Furthermore, I cannot even select the property. I can find it when I search the class DAQmx timing class, but I am unable to select any of the "Advanced:[...]" properties regardless of the hardware selected. The "Advanced" properties should be shown under "More.." when clicking on the property node, but they are not. Any idea why I cannot select or even see that property?

I feel so bad for all of this smaller problems just popping up. Normally I have no problem with property issues and such, but unfortunately i cannot find any information regarding compatibility. I just downloaded the newest NI XNET driver (2023 Q1) and the problem persist. I am using LabVIEW 2022 Q3. Maybe the hardware I am using (USB-8502) is just not compatible, but I cannot find any information.

Your mod has earned its spot in my top 10 mods, and it has been extremely satisfying to use for making difficult tasks much easier. I like it just as much as Logistics Pipes. One of my all time favorite mods.

-Adding more than 7 colors for RS signaling. I was filtering 12-16 different items through the network with rs signaling, only to find that I ran out of colors to signal with. Or allow two-color signaling, like white/green, white blue, etc. this would exponentially increase the number of combinations of colors we could use.

Author of RFTools, RFTools Control, RFTools Dimensions, Deep Resonance, Immersive Craft, CombatHelp, NICE, Aqua Munda, Ariente, XNet, Interaction Wheel, The Lost Cities, Lost Souls, Need To Breathe, EFab, The One Probe and co-author of Not Enough Wands and RF Lux.

Holy smokes. Just started using this mod and I am so impressed. Works brilliantly and allows me to do so much. My only want from it is redstone functionality. If it were possible to receive a redstone signal at one connector and output at another that would be awesome!

Have you heard about any issues with charging Ender IO capacitor banks with xnet? I have this setup where the capacitor bank isn't charging, even though I've set the input side for the bank. The controller and Actually Additions farmer are properly powered by the same cable.

3a8082e126