Data Loss in Serial Read during Multiple Ports read situation

[crossrulz]

---

@MadanMohan wrote:

The dataframe structure is:

     Header | Msg ID | No. of bytes | Data 1 ..... Data n | CRC_Low | CRC_High | Footer

---

What are the header and footer characters?  How is the CRC calculated?

[MadanMohan]

Header is 0x01 and footer is 0x04 (but depends upon the data structure definition in the application) 

CRC formula = Header + Msg ID + No of bytes + data 1 +.. + data n

[crossrulz]

---

@MadanMohan wrote:

Header is 0x01 and footer is 0x04 (but depends upon the data structure definition in the application) 

CRC formula = Header + Msg ID + No of bytes + data 1 +.. + data n

---

Ok, what I do in similar situations is to read 1 byte until the header (0x01) is read.  I then read the message ID and/or the Number of Bytes.  At this point, you can read the rest of the message, verify the checksum (simple addition is not a CRC), and verify the footer.  If the checksum and footer pass, then you parse the data based on the message ID.  You can get an idea of this setup in the following link (I just put a lot of time into an example for another thread and don't have the time to put it together here right now): VIWeek 2020/Proper way to communicate over serial

[wiebe@CARYA]

---

@MadanMohan wrote:

Hi CrossRulz,

The dataframe structure is:

     Header | Msg ID | No. of bytes | Data 1 ..... Data n | CRC_Low | CRC_High | Footer

I have turned off termination character in VISA Config VI. Thank you for the reference, I shall go through it and use it for my implementation methods

Regards,

Madan Mohan

---

I'd first read "Header | Msg ID | No. of bytes". This has a fixed number of bytes. Get the No. of bytes from that message. Then read that number of bytes from the port. That will give you a deterministic cycle. No more need to accumulate the string in a shift register.

Of course this will interfere the reading of data of the other ports. I'd make a loop for one device, and then start it for each device. Make sure all used subVIs that take time are reentrant.

Sorry, you already turned on the parallel execution of the for loop. Are you sure it's working though?

The "number of generated parallel loops instances" needs to be bigger than the number if loops you want, and the actual number of loops "P" has to be wired. I can see that "P" isn't wired.

Also, ParallelLoop.MaxNumLoopInstances needs to be big enough (>what you need). You can put it to anything, really. Even 100000. The default is pretty low, 8 or 16? Not sure... 

[MadanMohan]

Hi Wiebe,

In one port there are more than 5-6 Msg IDs coming from the data source so filtering them from the data I read looks to be a resource intensive task, and there are also chances that only half of a data packet could be sent in one instance of VISA read that's why I'm appending them to shift register so that it could be parsed in my 'Process Data' SM case

The number of parallel instances has been set to 8 in the 'configure iteration parallelism' property since the number of ports used is 4

[MadanMohan]

Hi GerdW,

As you have suggested I have changed the read loop to another while loop and used the producer-consumer method by using queues and notifier. I have attached the vi of the read loop (Main page.vi), now I'm reading 1000 bytes in VISA read and maximum data possibility in a port is around 600 bytes so I gave this value. But, still I'm getting this overrun error (attached the screenshot). I'm not sure why this error is coming, I also used 'Bytes at port' property node just for testing purpose and I didn't see any error but in some case the data in some ports are coming empty. Please suggest me what to be done in this case, as I'm not getting a solution for this error

[wiebe@CARYA]

I'd put my bets on Process Read Buffer.vi. But that is just a hunch.

I'd log a bunch of data, and unit test that one first.

Reason I suspect it, it that it's kludgy (sorry). It could be cleaned up and probably simplified.

And that is a really weird place to put a Wait Until Next ms Multiple...