[INSTRM-289] Create test STS tables Created: 07/Feb/18 Updated: 08/Feb/18 Resolved: 08/Feb/18 |
|
| Status: | Done |
| Project: | Instrument control development |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Normal |
| Reporter: | cloomis | Assignee: | Yoshida, Hiroshige |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Can we get a couple of STS tables which we can actually populate, just to test the plumbing and the STS python module? In STSradio.conf terms, something like (timestamp plus float): LINE DT(F1,%y-%m-%d?%H:%M:%S?????) D9990(F2,%f) and maybe one covering all the basic types: LINE DT(F1,%y-%m-%d?%H:%M:%S?????) D9991(F2,%c) D9992(F3,%d) D9993(F4,%f) Call the columns anything you want. FYI the ????? in the timestamp was an arrangement to put the HAST timezone in the datafile: STS require(sd) data in that TZ but does not parse the trailing timezone string, and we wanted to make the timezone explicit even though it was ignored. Obviously if any of that has changed please adjust. In the immediate term I can test from the existing STS client charis.sum.subaru.nao.ac.jp. I'll open a second ticket for getting access to and from a proper PFS machine. |
| Comments |
| Comment by cloomis [ 08/Feb/18 ] | |||||||||||||||||||||
|
If we have known MCS keywords, we could also use those. Specifically, if there are obvious detector temperatures we could make that a datum now. | |||||||||||||||||||||
| Comment by Yoshida, Hiroshige [ 08/Feb/18 ] | |||||||||||||||||||||
|
Are you developing a STS client (actor) based on the STS client module David wrote (STSlib.py or STSlib.c)? Are you trying to collect and send data programmatically or parse some log files to extract the latest data? When you call a method that updates the internal dictionary of the STS library, you need to pass a timestamp in seconds from the UNIX epoch. In other words, it does not matter how timestamps are textually represented within PFS? I can create Integer, Real, Text, Integer+Text, Real+Text, and Float type data for test purposes and let you know their IDs. | |||||||||||||||||||||
| Comment by cloomis [ 08/Feb/18 ] | |||||||||||||||||||||
|
Yes, STSlib.c or preferably STSlib.py, though I'd like to modify the python version a bit before using it. I specifically do not want to run the external STSradio program and point it at log files, which was the recommended solution. Instead, an actor which sees all the PFS keyword traffic will forward some of that to the STS using the STSlib.py scheme. That is what I'd like to test for real. The timestamp representation was only required for the STSradio log file parsing. I should perhaps not have sent it as an example. For the test tables, those would be perfect. Thanks. | |||||||||||||||||||||
| Comment by Yoshida, Hiroshige [ 08/Feb/18 ] | |||||||||||||||||||||
|
I have defined six (6) data sources. They are in the "Playground" public data set. Below is the list of sources and their "datum IDs" (STSradio IDs). It is very important for us to use the correct IDs! There should not be any difference between Float and Exponent (both are for real numbers).
| |||||||||||||||||||||
| Comment by cloomis [ 08/Feb/18 ] | |||||||||||||||||||||
|
Thanks! I'm calling this done. I'll probably test early next week when I can focus on this. And yes, I am aware of the importance of using the right IDs. Scary! |