Neosoft Technologies
Support Forum: Neosoft DQMH TestStandifier
Solved!
Hi Anthony,
You should have a stop tester seqeunce call to actually close the tester.
What may happen is that TS is caching the tester and it stays open (but idle) until you unload modules (TS Seq Editor menu -> File -> Unload all modules).
It is supposed to close it !
The TSifier specifically script a VI which finds the tester and makes use of user32.dll to simulate closing the window (like if a user clicks on the Windows' window red X button). The call is made twice : one to stop the etster, and the second to actually close the window and so making it leaving the memory.
Unless the tester was modified to alter the default behavior, it should work. At least it works on many projects already (ours) and until today nobody reported this kind of behavior.
Did you modify the tester default behavior ?
Would you be able to share your code ?
Hi Michal !
The question of releasing the TSifier as an open-source project will be discussed internally and I'll post a response here.
I use Round Trips in TS for one main reason : debugging thanks to the tester.
This is particularly useful when your are using Cloneable modules. If, for any reason, your clone ID isn't / cannot be tied to the TestSocketIndex, and you are using a batch or parallel model in TS, it might become difficult to see in the Tester where and when is issued a request.
If you wanted to trace in the tester when a request is done, you'd have to add a Status broadcast in all your MHL states.
Instead of doing this (which is annoying and takes time), I use a round trip. The round trip broacast the reply, so I've got that for free (casted !) in the tester. Then I can format into string (in the tester only) the answer in order to display that into the Status indicator of the tester.
Also, sometimes I modify the Round trip broadcast to embed the request payload AND the reply payload. Sometimes it is difficult to see what were the parameters given from the TS sequence, so I like to trace that in the tester. This way I can see in the tester what was the input of my request and the corresponding reply.
An idea excahnge was posted on the DQMH Idea Exchange forum to have this done automatically when creating a Round trip... who knows, maybe we'll see that feature soon.
@bienieck a écrit :So, in the end, you can monitor every interaction with the module in a single place—the tester. Is that correct?
Yes, every round trip in fact. If I explictely don't want to trace my request I would create it as an R&R only.
One more question: why is the termination monitor "injected" into every request? IMHO, the module API should be designed so that termination monitoring is handled by the request caller (such as SeqEdit). There should be a short request timeout and short MHL cases (just a few seconds at most). This way, the caller (SeqEdit) can decide how to handle a timeout. Since you're adding an RTE callback, you could also include placeholders for timeout handling there.
The blocking action is in the request when it is waiting for the response.
If a user decides to modify the timeout for let's say 30sec, then you would have to wait 30sec to actually stop your code module.
Which is not acceptable.
The TSifier is a tool, and I can't control who's doing what with their module. Therefore I add the termination monitor in every request.
If someones designs its module correctly then, yes the termination monitor will be unuseful and the RTE callback will do the job. I think this a more advanced architecture that would not be understandable by everyone. Also, sometimes you 'cannot' make a MHL to be fast : I've seen instruments taking several dozens of second to actually return a value for example...
By the way, when creating a module sequence file, you might consider using a sequence file template (with callbacks and similar configurations). This way, when recreating the module sequence file, the tool could prompt you to select a default template or an alternative file—the latter being a version with your modifications already applied. I think this could be a straightforward way to avoid manual adjustments during regeneration (which you mentioned as the only manual step needed when generating again; I saw your presentation 😉).
Very good idea !
Maybe in the next version of the TSifier ?! Who knows ! 😉
