It doesn't look like this function sends anything to UI - just setting an epoch. Does f/w need to log treatment start/end time or can UI do that from its own clock.
Also, formatting doesn't make sense to me. fpgaID is in between HD and FPGA versions !!!
I think it should be like: v<hdMajor(%1)>.<hdMinor(%2)>.<hdMicro(%3)>.<hdBuild(%4)><' '>v<fpgaID(%5)>.<fpgaMajor(%6)>.<fpgaMinor(%7)>.<fpgaLab(%8)><' - '><compRev(%9)>
or move the fpgaID at the end of the FPGA versions.
Not Always. ovData will stay True until the Reset function is called (which is then assigned ovInitData's value). Our handler only calls the Set/Reset function. No parameters are given.
The message ID should not be passed to the command. Each dialin function should correspond to a single message ID. The channel ID should not be passed to the command. This should be defined in the dialin command. The HD and DG simulators are to be separated into different classes. If you pull staging you'll see what I mean.
This message is a very dynamic message for rapid testing. A screen in the simulator gives the user the ability to set the source, type of data, and length of the message, and nothing is known in this dialin command. So this is the required structure of the function. I can't imagine how else we could have a function to support that dynamic screen.
The original file didn't have the copyright so couldn't find easily what was the actual dates, just put some dates. Bamboo will later update the copyright with correct information.
I wasn't aware the ms needed to be in multiples of 10ms. I've created a case DIAL-115 to add constraint enforcement across dialin. For now, I think new code should incorporate some form of constraint enforcement. So if you could just apply it here in DIAL-115 I will address this in other parts of dialin. I think the docstring describing the constraint is useful and should be kept if it's already there even if we add code to check the constraint as well.
