Reading LVars over WideFS

[Paul Henty]

Hi Pete,

One of my DLL users has a problem with reading LVARs over WideFS. It's fine locally.

I've tested this myself and I get the same problem here.

For best performance my DLL writes the LVAR request and reads the result in one process, as described in the documentation.

1. Write user address to 0D6C
2. Write LVAR name to 0D70
3. Read result from user address

However over WideFS this really isn't working as expected. The value returned is from the previous LVAR request (if a long enough gap is left between reads)...

1. Read LVAR1
2. Sleep
3. Read LVAR2
4. Sleep
5. Read LVAR3

etc..

This gets the previous LVAR value.

If there is no gap...

1. Read LVAR1
2. Read LVAR2
3. Read LVAR3

They all get the same value.

I'm guessing this is because the process() on WideClient is not synchronous with the network updates so it's not waiting around for the correct result to come back. It's just supplying the cached value it already has in the user offset.

The only solution I can see is to get the result a short time after requesting the data (i.e.  in two process() calls). This is not great because it'll be much slower and I can't be sure of how long to wait. If I find a delay that works on my network, it may not work on another developer's, or end user's network.

Do you think there is anything that can be done in your code to help with this? Or do you have any other suggestions for a solution?

Thanks,

Paul

[Pete Dowson]

On 11/13/2018 at 6:12 PM, Paul Henty said:

For best performance my DLL writes the LVAR request and reads the result in one process, as described in the documentation.

1. Write user address to 0D6C
2. Write LVAR name to 0D70
3. Read result from user address

Actually it doesn't say to read the result in the same process. I don't think that can work with Wideclient. The L:Var is obtained by a request to PANELS.DLL in the Sim.

The way to do these things (and there are others, for instance when reading weather stuff), and especially in WideClient, is to write something impossible to your offset, and the offset address, and the L:Var name, which can all be one process. Then, separately, wait for your impossible value to change in your offset. That would obviously require some sort of process loop.

If the application needs much more immediate access to such values there's really no way other than running only on the same PC. Even then I'm not sure it can be guaranteed in the same process.

Pete

 

 

[Paul Henty]

I understood this to mean that you can use the same process call to read the value:

Quote

Both 0D6C and 0D70 can be
written together or at least in one Process call, and the result of a
read can be read immediately, even in the same Process call.

and doing that seems to work fine locally.

I get the idea for the loop, but that would be too slow for monitoring many LVARs in real time.

I'll make a note in the DLL documentation that the LVAR feature doesn't work over WideFS.

Thanks,

Paul

[NaMcO]

Thank you both. I read this and will try to do it the old way, see if i can get around it.

Cheers,

Nuno