[INSTRM-1401] Populate target table Created: 15/Oct/21  Updated: 19/Jan/22  Resolved: 19/Jan/22

Status: Done
Project: Instrument control development
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Normal
Reporter: hassan Assignee: chyan
Resolution: Done Votes: 0
Labels: EngRun
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Blocks
is blocked by INSTRM-1497 check `update` method of opdb library Open
Relates
relates to INSTRM-1388 Poor convergence quality during Sep 2... Done
Story Points: 1
Sprint: PreEngRun4, EngRun3Cleanup, PreEngRun05 A, PreEngRun05 B

 Description   

Please:

  • Populate the target table based on historical Sept eng run data.
  • Load the target table based on the most recent targets prior to the next run.


 Comments   
Comment by chyan [ 21/Oct/21 ]

The ics_cobraCharmer produces the trajectory for all the moves. We should be able to insert those information into database.

Comment by chyan [ 28/Oct/21 ]

A branch of fpsActor is pushed to GitHub to address this ticket.

Comment by chyan [ 29/Oct/21 ]

Talked to Chih-Yi today and he pointed out there are two way to implement this. One solution is obviously in fpsActor and another one in down to the function of moveThetaPhi in CobraCoach.py since it calculate the angle for theta, phi for each iteration before the move.

Comment by chyan [ 14/Nov/21 ]

Turns out this is more complicated than what I thought.  The reason is addressed here.  cobra_target contains information from different levels BOFORE the cobra is actually moving.  It require visited, iteration (FPS), cobra location in mm (FPS), target location in mm (FPS), motor map information (cobraCoach), theta and phi angle (cobraCoach), theta and phi steps (cobraCharmer), theta and phi on-time (FPGA).   To insert only predicted angle is easy.  However, to input all those information at once is not straight-forward.  A possible implementation is passing an object all the way down to FPGA level and write information in every step.

Comment by chyan [ 14/Nov/21 ]

Two branches in ics_fpsActor and ics_cobraCharmer is pushed for populating target table.  This version only populated the information in cobraCharmer level.  We need to think about how to get information down to FPGA level (steps and on-time).

Comment by chyan [ 06/Jan/22 ]

I would need help from Kiyoto Yabe regarding the database prime key issue. Currently, the cobra_target table is populated with (pfs_visit_id, iteration, cobra_id) because cobra_match table requires those information (prime key referencing). So, I may need a function that only updating the opdb table instead of writing.

Comment by Kiyoto Yabe [ 06/Jan/22 ]

Maybe I don't understand what you want to do, but do you want to (for example) insert information other than (pfs_visit_id, iteration, cobra_id) into cobra_target after populating cobra_match table? Could you tell me example use cases?

There is opdb.update method already implemented, but it's not fully tested. I'll check it to see whether it works properly.

Comment by chyan [ 07/Jan/22 ]

I tried db.update function, but it did not work.  There are two places I need to update the cobra_target table.  The first place is in ics_mcsActor. We need it before writing to cobra_match table. So, in MCS we only write three columns. However, we need update this table when we gather more information on where the cobra will go. I did some work arounds. The target table is populated and tested with bench system.

Comment by Kiyoto Yabe [ 11/Jan/22 ]

Perhaps I missed the discussion point in the last meeting, but does simply swapping the relationship between `cobra_target` and `cobra_match` solve the issue? I mean (pfs_visit_id, iteration, cobra_id) of `cobra_target` refers `cobra_match`, so that you don't need to populate `cobra_target` first. This relationship looks a bit strange to me, but it is probably OK practically.

Comment by chyan [ 11/Jan/22 ]

Thanks for the comment, let me talk to Craig first. Then we decided how to do it. I think this is because cobra_match needs a reference from somewhere. Therefore, a pre-existed table is required.

Comment by Kiyoto Yabe [ 11/Jan/22 ]

Thank you, I got the problem.

Generated at Sat Feb 10 16:35:04 JST 2024 using Jira 8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b.