We are using COM7on the RMC of an sbRIO-9607 for two-wire RS485 and the bitfile generated in LabVIEW 2018 still works fine (just generated from a CLIP, no other code added, just a dummy blank FPGA VI). Having upgraded to LabVIEW 2020 the LabVIEW application still works fine with that old bitfile on the FPGA, but if I recompile the bitfile in 2020 the first byte sent on the serial port is lost or malformed (receiving LabVIEW programs do not see a byte there, but other applications see a 00h).
I have seen similar behaviour when an RS485 interface switches from rx to tx too quick for the receiving end to have switched yet - causing the receiver to not get the first byte...but I am not sure yet if that is the case now...Has anyone else seen this, or know of anything that might explain it (perhaps the 2020 FPGA code changes the timing, making it too quick for most RS485 interfaces to handle...or perhaps the byte is not sent properly at all...).
For now the old bitfile does the job, but having it lag in version might bite us sometime in the future so figuring out the issue would be better...
Just to check my understanding - we don't receive the first byte but all future bytes send correctly? Is there a one-cycle lag in this (i.e. your first byte becomes your second byte) or is the first byte lost and then the second byte is the correct second byte?
The Vivado compiler changed versions from 2017.2 to 2019.1, so it's possible that the timing on this has changed. It may be worth raising a ticket with Vivado to see if they have any ideas around this as well, as this is the main change between LV2018 and LV2020. Please post back here with findings if you do so.
The first byte is received as 00h, the rest comes as expected. So if we send a string starting with 0104...the receiver sees 0004...For some reason LabVIEW/VISA does not register the 00h, so if we send "Hello" the receiving LabVIEW application will just see "ello". Swap back to the 2018-bitfile and we get 0104... and Hello as expected.
Working a bit more on this we see now that when the CLIP generator in 2020 is set to generate for the sbRIO-9607 the only CLIP file format you can select is version 2,0. Now, in the 2020 project you can add the 9607 as a target, but if you do this from scratch and need to deine a CLIP for the RMC - you are not allowed to select such a CLIP file (even though it was generated in 2020) (!). In our case the linking to the CLIP was already in place as the project was converted from 2018 to 2020 - but this might then be the reason why regenerating the bitfile in 2020 fails. The CLIP file link has due to the project conversion been established, even though 2020 would normally refuse a CLIP file of that version.
This seems to be a bug in 2020. sbRIO-9607 target is still supposed to be supported as far as I can see, and that assumption is also supported by the fact that you are indeed allowed to add it to 2020 projects and compile for it. However, the RMC target will not accept the CLIP files that the 2020 generator produces - so you are effectively blocked from working with the 9607 RMC in 2020 unless you bypass that block by importing a 2018-project...In which case you might then see the kind of strange misbehaviour we are now seeing from the 2020 bitfile 😫 (which you can then only bypass by generating the bitfile in 2018 instead.
The issue with 2020 not accepting CLIP files, even the ones generated within 2020, is separate from the serial port issue.
The serial port issue has now been proven to apply to multiple sbRIOs and mezzanine boards which all work fine with the 2018 bitfile.
Everthing else can be kept constant and the problem pops up with the 2020 bitfile, and goes away with the 2018 (or 2019, both work) bitfile.
I also hooked up an oscolloscope to see if it was a timing issue alone, and it turns out to not be: The analog RS485 signal before and after the change in auto-compiled FPGA code contains a 00h character instead of the character sent, as seen here:
The oscilloscope correctly interprets the 2018 signal as Hello, and the 2020 signal is " ello" with the first byte a NULL (00h).
Can you check if the CLIP file generated in 2020 worked correctly in the older LV version ?
It does sound buggy, but based on my experience from the other thread, it appears that the CLIP creation in 2020 is alright, albeit not the RMC Socket module.
NI has recreated the issue and have found it to be an issue introduced by the compiler so they have handed it over to Xilinx....The only solution for now is top keep using the 2018-bitfile.