It is not possible to use a NI-made RMC board like the 9694 and a custom-made RMC board which implements an additional serial port at the same time. This is why your socketed clip option disappears from the project after adding the 9694. The 9694 uses that RMC IO so it can no longer be accessed via a socketed clip.
However, additional DIO can be implemented on a custom RMC board that also includes a serial port. You can read more about implementing ASLR:2 and DIO on your board in the RMC Design Guide.
You could also use the 9694 along with an external serial transceiver board, like this digilent product: https://store.digilentinc.com/pmod-rs232-serial-converter-and-interface-standard/. In this case you would not add the 9694 to you project. Rather you would create your own CLIP with the sbRIO CLIP Generator that implements ASLR:2 on pins of your choosing, which should be routed out the 9694. As long as you connect the external serial transceiver to the 9694 correctly you should be able to access the serial port as if you had implemented one on a custom RMC board.
I have followed the nice pptx to define a socketed CLIP. My goal is to use the DIO2 pin on a sbrio 9607 to import a Clock from the RMC board.
The process of the CLIP definition as shown in the pptx worked flawlessly.
However, when I want to integrate the CLIP into the project, the "RMC Socket Properties" Window throws an error. After selecting the newly created CLIP, I am unable to click "OK" because there is the following Error:
"Declaration is not valid.
Warning Info: This CLIP may have been generated for a different version of LabVIEW than you are currently running. Therefore, this CLIP might fail to compile or might not function correctly. To fix this issue, regenerate the CLIP in the latest version of LabVIEW."
This is strange since I didn't even close Labview or the project between the creation of the CLIP and my effort to embed it. Some details on my CLIP: It uses no additional interfaces, no DIO pins, and I only specified DIO2 (as input) to be the source for the imported clock.
I also can't embed any of the DevKit example clips due to the same reason (some error about another Labview version).
I am using LV2020.
I have the same issue as you tobiy. NI thinks it is a corruption of the RIO DRiver, but repairing it does not help. I have 2020 installed on another machine and it does not display this issue so there is obviously something fishy on my main development machine, but it seems I will have to uninstall everything to get it to work, unless NI finds out more about it...
Ok, so it seems (at least) that I did nothing wrong.
Do you have other versions of LV installed on the machine where you get the error ? I have LV2019 on the same machine, but don't have the sbrio packet for it, so I thought that there shouldn't be any conflicts.
Like you, I am quite hesitant to reinstall considering the amount of time it takes
No the machine with the problem has actually never had anything but 2020 installed. I updated it to SP1 later, but that did not affect the issue either.
I had the NI Packet Manager update everything to the most reason version including the LV2020 Service pack. No change. Won't load the CLIP into the project.
As Friday dusk was coming I felt a little stupid and launched LV2019, for which I don't even have the SbRio module installed. Strangely enough, it let me select the same sbrio-9607 from the targeted project templates and it even let me load the CLIP clock without any issue (the same clock that I had compiled in LV2020).
So it seems using a wrong version of labview is one way to get rid of labview complaining about the wrong version... or something like that.
So thanks again for the initial powerpoint documentation. It is very instructive, if Labview decides to cooperate.
There is an issue in LV2020 using clips on Windows machines that have the decimal point symbol set to ',' instead of '.'
A workaround to this is to add the following line to the bottom of your LabVIEW.ini file
LabVIEW.ini file typically be found in C:\Program Files (x86)\National Instruments\LabVIEW 2020
Another option is to change the decimal symbol in the Windows locale from ',' to '.'. Also may need to set the separator symbol to ',' if not already so.
I found that changing decimal point from "," to "." works while adding line in .ini file seems to not work.