Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RCB listener and Network Traffic #243

Closed
IniterWorker opened this issue Jul 23, 2020 · 4 comments
Closed

RCB listener and Network Traffic #243

IniterWorker opened this issue Jul 23, 2020 · 4 comments
Labels

Comments

@IniterWorker
Copy link

Hello,

Maybe do you have some hints for me? It's pretty hard to find advanced information about your implementation and the standard iec61850.

I did some tests with the IEDScout software client to try to figure out that it isn't a big deal. But, I'm looking forward to some hints before going into the production environment.

I'm implementing an MMS with an RCB, and I'm wondering if the basic polling example is enough not to flood my network when a client listener is connected to my RCB block, mainly if only the ".t" timestamp is the one changing.

I took the time to look into your code, and I observed some particular case handling the value change with different triggers. My question here is a simple need I to take care of my value change to change the timestamp, or is it already handled by the library?

Could you point me in the right direction? Thank you for any help you can offer.

Best Regards,

@mzillgith
Copy link
Contributor

Hi,
When only the timestamp changes usually no report is triggered.
You have to update the timestamp in your code it is not updated automatically.

@IniterWorker
Copy link
Author

Hi @mzillgith,

With the present answer, you say that the RCB handles the mechanism to update only on value triggering changes and that I don't need to care about when the update of ".t" will be. Is it correct?

while(true)
{
  Lock
  ReadMyState
  Write.q
  Write.t
  Write.sState
  Unlock
  Sleep
}

@mzillgith
Copy link
Contributor

Yes. That's correct. The order doesn't matter in this case (when lock is applied).

@IniterWorker
Copy link
Author

Thank you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants