Since more than one year now, I use the stack 3 to take pictures on our main vision products. It use two AT (mostly C5 SCT) cameras that reconstruct huge carts to control components on it.
We set up the AT to take fixed size images with a maximum of profile (5400). We also open all Ethernet board parameters like Jumbo packets to there maximum. We set also the scsp packet size to it’s maximum.
With the stack two, no problem at all. When we use stack 3 we can see this :
when we should have this :
We also understand that when this happen, we got verry small pikes (in red in the image) contrary to the huge pikes that we have normally (in green) with the task manager :
When we switched from stack 2 to stack 3 or the inverse, no parameters are changed.
The stack 3 used a composite image to get data. Both camera are on the same Ethernet board, without any other element on it.
We suspect that either we get a improper network settings or a problem with stack 3 like bad uses or missing a parameters that need to set up ? Or have you any ideas ?
With our experience of the new GenTL stack (3rd Gen stack) I expect no difference in performance or stability.
The first image clearly shows lost packets, which you also should see when checking for corrupt frames or Incomplete frames. if you want to do it programmatically.
I strongly suspect a setting which is different in these two setups. And the one which is set from CVB is the PacketSize. So this would be the first thing to check. Has the packet size the expected value?
There is a difference how the packet size can be changed during the startup of the VIN-Stack and the GenTL-Stack.
With the VIN-Stack and loading the GenICam.vin file, you use the setting from the INI-File. Mostly configured over the GenICam Browser.
If you use the GenTL-Stack you have to set the feature programmatically. e.g. directly via the “GevSCPSPacketSize” feature.
p.s.
Please check if you are allowed to post these images publicly. If not, you should delete them.
As I wrote on my message, we do set up the scps packet size at is maximum like this, directly after connection to the device and get the nodes we need : m_node_scpsp_packet_size->SetValue(8192);
Unless we need to do it at another point, normally we are ok on this.
@Sebastian
We already put this value on our code. And we have the problem.
We will check the value for each packet we will received.
How can we check for errors ?
Hi @Chris
Sorry for my late answer, I was on sick live.
We planned test with our client during August, so I cannot give you news for now.
I will give you that when I can.
I was able to do some test today about this problem directly with our client system. It take some time to plan that for different reasons, that is why I write about it now.
So, we check that the node scpsp packet size is always the full value, and if there is a problem accessing it, to have an alarm about it. So far, no problem, we can set it each time we are connected to the camera.
Also, I’m coding now (after this message) the cheking of missing packet value each time we received a image from the camera. I will tell you what happen with that as soon as possible.
For now, as far as I am in my test, I always have the problem (the images can be display here the time of the resolution of the problem, so no worries about it) sometime :
Beside the scsp packet size, on the ethernet board, we set up the jumbo packet to the maximum, the reception and transmission data to the maximum too.
As a reminder, we received N small images (20 profils or pixel in height) and we reconstruct the all images of 4900 profiles/ pixel in height. We set the CVB buffer to N = 4900 / 20 = 245 small images, for a production time of 8 secondes (each 8 secondes we get a trigger that inform us a new product is here to see). The internal CVB buffer are for now 245 * 3 =~750 buffer of 20 profiles for one camera. We use two AT C5 SCT cameras.
Hope those information will help you tell me what the problem is.
first of all thank you for the detailed description, I will check on this with @Sebastian in more depth today.
Allow me some additional questions for now:
Do you see this behaviour with each Image or only occasionally?
There are 2 Packet Sizes that have to be taken into consideration, one that you set on the "Device Nodenmap, which is very likely the “GevSCPSPacketSize”.
Then there is another PacketSize in the “DeviceTL” Nodemap. This one is to configure the transportlayer. Usually CVB does the configuration of the TL for you and only setting the correct value in the Device Nodemap should be enough. However I have seen cases where this was not the case.
So just to finally rule out the packet size, after setting it on the device, you could read out the setting from the DeviceTL Nodemap as well just to be sure.
PacketTimeout
In the DataStream Nodemap (yet another Nodemap available through the NodeMaps on the discovered device) there is a PacketTimeout value which is usually set to 200. In the past we had customers with similar behaviour as you have where setting this value either to 0 or a very high value (to pretty much have an endless value) this behaviour was fixed.
What happened was, when the device did not get any new triggers but the image was not yet ready with being taken, the already taken packets were sent over to the PC containing old image data from the buffer that was not yet overwritten due to the interrupt because of the missing trigger along with the PacketTimeout pushing the camera to send the data.
This happens usually if you have a conveyor belt or a camera scanning along an object being triggered by a rotary encoder or PLC. Now at some point you might have to stop your belt or scan to avoid collision in the following process along the belt. In these cases, once the triggering stopped for a short time, the camera immediately sent the data to the processing machine.
If I interprete your images correctly, this happens not only once. At a certain point in the scan process (you seem to be scanning horizontally with the camera moving from left to right) the trigger might start stuttering, meaning we have a gate high which is interrupted for a short time exceeding the packet timeout. This happens with the next frames again and again leading to this staircase kind of blocks we see.
This is just a rough guess but if you change the PacketTimeout to be indefinite OR monitor your trigger signal (accuracy of measurement method < PacketTimeout) we can validate if we see interrupts in the signal which have to be taken care of.
I am looking forward to hearing from you, the problem seems complex but I am sure we will find a way to solve this.
