I think what you are asking is "when cycling the power on the VxWorks image, it keeps coming up with the same participant indexes, so remote participants ignore it and nothing connects", which is a known issue and covered in the knowledge base.
I think that the "aRandomOrIncrementingValue" isn't an api thing, I think it is a placeholder for you to decide what goes in there.
When a DDS node is disconnected and econnected, specifically in vxWorks, the DDS node within vxworks either takes to long to come back on line or never comes back on line forcing us to recycle power. As you stated "This is a know issue" so what is the fix for this issue.
When a DDS node is disconnected and econnected, specifically in vxWorks, the DDS node within vxworks either takes to long to come back on line or never comes back on line forcing us to recycle power. As you stated "This is a know issue" so what is the fix for this issue.
Save/read/increment a counter to NVRAM (if you have some)
Read a CPU's cycle counter (if it has one)
A real-world battery-backed clock (if the board has one)
An appInit task that updates a shared memory variable by opening a socket to a service someplace and gathering some information (like NTP, updates the system clock to real-world [which you may be doing anyway]) ...and then you can use the real-world clock as the seed for setting the appId etc
You'll note from the parantheticals, we can't answer the questions succinctly, as we don't know what you have on your board/available to you. How you choose to do it is a system architecture/design question.
Hi,
Looks like something got dropped when you posted.
I think what you are asking is "when cycling the power on the VxWorks image, it keeps coming up with the same participant indexes, so remote participants ignore it and nothing connects", which is a known issue and covered in the knowledge base.
I think that the "aRandomOrIncrementingValue" isn't an api thing, I think it is a placeholder for you to decide what goes in there.
If I missed the point, can you restate the issue?
Regards,
Rip
When a DDS node is disconnected and econnected, specifically in vxWorks, the DDS node within vxworks either takes to long to come back on line or never comes back on line forcing us to recycle power. As you stated "This is a know issue" so what is the fix for this issue.
When a DDS node is disconnected and econnected, specifically in vxWorks, the DDS node within vxworks either takes to long to come back on line or never comes back on line forcing us to recycle power. As you stated "This is a know issue" so what is the fix for this issue.
Possibilities include
Save/read/increment a counter to NVRAM (if you have some)
Read a CPU's cycle counter (if it has one)
A real-world battery-backed clock (if the board has one)
An appInit task that updates a shared memory variable by opening a socket to a service someplace and gathering some information (like NTP, updates the system clock to real-world [which you may be doing anyway]) ...and then you can use the real-world clock as the seed for setting the appId etc
You'll note from the parantheticals, we can't answer the questions succinctly, as we don't know what you have on your board/available to you. How you choose to do it is a system architecture/design question.
Regards,
rip