Multiprocess variable

[poledna]

made changes to allow multiprocess variable communication to allow issue #22 change of report rate when necessary.

[Pratyush-das]

Hi poledna,
thanks for creating this branch. I tried your code and The PMU connection tester still does not show the changed rate. I am confused about where is it getting more data in 50fps when I have set it to 10 fps. This is strange to me. I think it is a good idea to contact the community behind PMU connection tester and ask for help.

[poledna]

hey Pratyush-das,
that's odd.
I've made some extras test here
Before changing the framerate

after changing to 30fps

after changing to 5fps

As you can see it effectively changed the received frame/rate on the bottom of the screen. The Frames/sec did change but it just didn't change the Configured Frame Rate Field even after CFG2 request .

as a sugestion why dont you use the pypmu.PDC module? It is a very good module!

[Pratyush-das]

I am having the same results now. Thank you for your help and suggestion.

[Pratyush-das]

By pypmu.PDC you mean the tinyPDC? Do you think it can be modified to serve this purpose? Furthermore, I would need to connect to at least 2 PMUs.

[poledna]

yes I mean tinyPDC.
I've connected up to 23 PMUs using tinyPDC with tinyPDC modified to my needs. I needed UDP support. So there is a branch that is the UDP support on the master repository.
It depends on how the data will arrive at your PDC(One PMU per port or multiple PMU per port). But it is possible.
Frankly I think it is easier to deal with python then openPDC/PMUConnectionTester.

[Pratyush-das]

Hi Yuri,
I am trying with tinyPDC, now just with one PMU. I have a few questions and I shall be really grateful if you can guide me in the right direction:

1. How to connect more than one PMUs ? I did not get what you did with the following code:
   pdc = Pdc(pdc_id=7, pmu_ip=socket.gethostbyname("rasp"), pmu_port=10000,method='udp')
2. I am trying to get the real-time frames per second (like what we saw in the PMU connection tester), along with the configured frame rate. I could not find any method for that yet. It would be nice if I can do it at the PDC end.
   Thanks in advance,
   Pratyush

[poledna]

I'll answer as numbers to make it easier to follow:

1.1. the line you mentioned it is a example of a PMU application using UDP. I was testing with a raspberry pi, so the socket.gethostbyname("rasp") returns the IP addr of the raspberry Pi, that i allocated in my DNS as a fixed IP addr. For example socket.gethostbyname("localhost") returns '127.0.0.1'
pdc_id is the id of the PDC not the PMU. you could have different numbers for PMU and PDC
pmu_port is the port that the data come in and the
method is UDP, I was implementing Multicast but it isn't fully functional yet. how method is a KeywordARGumment the default value is 'tcp' and it sets the PDC to TCP communication as excepted.

1.2 How to connect more PMUs to tinyPDC? As i see it there are effectively 2 alternatives as it is right now.
if the data was already concentrated the PDC module has the capacibilty to receive a package of multiple PMUs (this is how i got 23 PMUs), but i also had some extras PMUs that I needed to receive data, so there is something that I didn't see a solution yet. That is receiving in the same port data from multiple PMUs with different IDCODEs from different IP addresses, it is possible, but when you send a get cfg2 frame you'd need to save more than 1 configuration. and unpack each code accordingly. So what i did to not have to make even more changes on the pyPMU code is for each PMU i created a instance of a PDC in a new process with a new port(but the use of a new port was because my PMU isn't openSource and i couldn't change the IDCODE, so if i received data from different places in the same port with the same IDCODE could cause instability). In the whole picture i get all the data using smaller PDCs. it isn't the prettiest solution but got around the issue. It depends on how your infrastructure of the WAMS is and will be and how you want it to be.

2. In the matter of the changing the report frame rate on the PDC end, in the IEEE C37.118.2-2011 in table 15 it lists 6 Command Frames available: Turn off Turn on Send: HDR,CFG1,2,3 and Extended Frame but you could as an alternative to what you were doing is to create a new Command Frame in which you'd change the bits 11-8 that would create a new Command Frame, and then use it in both sides (PMU and PDC). Oh I now see that I answered I totally different question, but how i see it might be relevant for you, i'll leave it there as food for thought. Real time frames for second really there isn't implemented, but the receiving end of the PDC is blocking so you can know when the last package has arrived and time it till the next one and calculate the FPS, you could you time.time for example and subtract one from the other when necessary. you know you got one package at a x interval you can easily interpolate the FPS. it really doesn't exist on the pdc module... yet. The configured frame rate is easier to get when you execute:
   config = pdc.get_config()
   you get the cfg frame then simply execute:
   frame_rate= config.get_data_rate()
   it should give you the configured frame rate of the PMU sent CFG2 frame

[Pratyush-das]

Hi Yuri,
I ended up using multiple PDC instances for multiple PMUs and they work satisfactorily. In each PDCs I manually calculate the FPS and Data Rate (Bytes/Second... size of each packet/time between two packets). I do not know if there is a better option. Is there any way to communicate between two PDCs?
What I want to do is add the data rate (bytes/second) from two (or more ) PDCs to get an idea of total network traffic and run some customized control action to reduce reporting rate of one or more PMUs.
Any insight or idea is greatly appreciated.
So far what i have come up with is to use sockets to send the data rate to an instance of some algorithm, it gathers the data rates from all PDCs and calculates the total.

[poledna]

For what I understand that you're doing, there is a way to communicate between PDC instances, you should be able to communicate between instances with some setters and getters or a shared variable (for shared variables keep in mind that you might need to share that variable between various levels of threads so it might be easier to use a setter of a shared variable, but it needs some checking). Another possibility is to have a "multi PDC manager" that would do this job, but i have a feeling that you're already doing this (To use the main function as a porgram that gets and sets all RR).
On the matter of the reporting rate on the network, if you know the packet size it and the RR is fairly easy to determine the network traffic, but i find complicated to change the RR mid transmission without acknowledgment of stability, should you lower the RR in a unstable time you'd be sending less information in a critical moment, so I'd be aware of that.

So far what i have come up with is to use sockets to send the data rate to an instance of some algorithm, it gathers the data rates from all PDCs and calculates the total.

From what I understood, correct me if I'm wrong, your "problem" is that you want you PDC to change the RR mid stream and calculates the overall data arrival size on the network from all the PMUs and then decide if that PMU should have the RR lowered of increased, so to do that you're using a second socket connection that would by itself increase the network usage. To that I'd suggest again to create a NEW CommandFrame, I know it doesn't sound easy but it isn't complicated, it depends on how much time do you have to do it. Should you need help with this just give us a shout.
Quoting myself about the CommandFrames:

1. In the matter of the changing the report frame rate on the PDC end, in the IEEE C37.118.2-2011 in table 15 it lists 6 Command Frames available: Turn off Turn on Send: HDR,CFG1,2,3 and Extended Frame but you could as an alternative to what you were doing is to create a new Command Frame in which you'd change the bits 11-8 that would create a new Command Frame, and then use it in both sides (PMU and PDC).

On a third thought I think that this might be kinda of what you want:

give me a feedback if I got the gist of it or if i went to a TOTALLY wrong direction
With the Send of the NewCommandFrame and after you get a new ConfigFrame you should be able to see in the PDC the new RR.

RR= Reporting Rate

Yuri

[sstevan]

Hey @poledna sorry for the delay.

Would you mind sending this pull request to the udp-support-v0.1?