DDEError when using the MeasureRepeated command

[fernando-vegaramon]

Hi @joshduran, I hope this finds you well.

I have been using brukeropus to control a Bruker Vertex 70 FTIR spectrometer. In our application, we are trying to generate IR spectra periodically and in coordination with a modulated feed in our experiment.

We initially called each individual measurement using the measure_sample() function in brukeropus.control.opus. While functionally correct, each DDE round-trip added around 2 to 2.5 seconds of overhead in addition to the measurement duration, thus severely reducing the number of spectra we can generate in a given timespan. To eliminate the per-spectra DDE latency, we attempted to batch the sample measurements by writing a custom query that executes the MeasureRepeated (rather than MeasureSample) command, e.g:

cmd = f"MeasureRepeated(0,{param_str})"
response = self.opus.query(cmd, timeout=timeout)
where param_str also includes parameters relevant to the repeated measurement function in OPUS such as dlr (delay between repeats) and rep (number of repeats).

In OPUS itself, this query executes correctly (as we see the spectra files being written on disc and show up in the OPUS software). However, the following error is raised in Python once the final scheduled measurement is taken and loaded in OPUS:
File ~xxxx\brukeropus\control\dde.py:180, in DDEClient.request(self, item, timeout)
178 DDE.FreeStringHandle(_self_._idInst, hszItem)
179 if not hDdeData:
---->180 raise DDEError("Unable to request item", _self_._idInst)
DDEError: Unable to request item (err = 0x4002)

Please note this error is also raised when sending a raw_query() in the same format, so I do not think it is related to the parsing of the DDE response. It appears OPUS runs the measurement but doesn’t return the expected DDE response.

Any guidance you can provide to make the use of the MeasureRepeated command viable in brukeropus would be greatly appreciated. We are running version 8.7.41 of OPUS.

[joshduran]

@fernando-vegaramon thanks for reaching out. I won't have access to my ftir to test this for a few weeks. One thing I might suggest you try is increasing the timeout time. I vaguely remember getting errors when the timeout parameter is too short for measurements. It'll execute the command, but if the function doesn't receive a response in time, it'll cause an error.

I would try setting up a short repeated measurement and making the timeout longer than you need just to rule this out.

Josh

[fernando-vegaramon]

Hi @joshduran thank you for your prompt reply.

It turns out that was indeed the issue. By increasing the query timeout parameter well-beyond the expected duration of the repeated measurements sequence, the exception went away and the batched measurement completes without error. It seems a generous timeout is necessary to accommodate for the delay in the DDE response.

One follow up question: We have noticed that this delay in the DDE communication changes substantially with the IR acquisition settings. For example, for NSS=1 the repeated measurements call runs within the expected measurement time plus an additional 0.5 seconds delay. On the other hand, for NSS=8, the call takes the expected measurement time plus 10 seconds delay. Do you have any experience on how this latency in DDE communication changes with other measurement parameters? This would be very helpful in terms of minimising this delay and/or adjusting our timeout parameter accordingly.

Thanks again for your help.