508 problems

[mhwlng]

apart from the stuff that rpalmer68 reports

here's some more problems

1)
I have my own weather stuff, (not using component manager)

and now I see :
Weather callback function error ...ogram Files\Promixis\Girder5\luascript\NetRemote.lua:148 7: unable to unlock mutex for Eindhoven Forecast Conditions

2)

girder now crashes every time at shutdown

In 507, I had to modify the W800RF32 component to stop the crashing

Close = function (self)
self:SerialCloseDevice() -- added
Super.Close (self)
end,

this doesn't fix the problem now

3)

adding require 'DMSupport' still hangs NR

adding require 'DMCore' does not hang NR

4)

making changes to the sunclock settings still has no effect

5)

Mike said :


the next iteration of G5 allows you to exclude devices from the devicemanager.

Is that already implemented, if yes, how do I do that ?

6)
some times, I see this (I am not aware of using any mutex in this code, it's just a girder event)

Time Date Source Details Payloads
11:43:28:515 1/5/2007 power meter Script Error: Could not aquire Lua Mutex.marcel v2.0.gml:\X10\power meter

7)

one time, I saw several 100 of this :

Time Date Source Details Payloads
11:41:37:335 1/5/2007 NetRemote NetRemote.SendImageFromURL is deprecated - use NetRemote.SetImageURL instead

I only use this function : NetRemote.SetImageURL ("WORLDMAP",url);

8 )

girder freezes regularly (when editing etc.) then I have to kill it in task manager

one time, when g5 hung, I saw :

Time Date Source Details Payloads
11:50:00:035 1/5/2007 DUI Subsystem LuaMutex blocked (TDUTabSheet.Destroy)
11:49:22:429 1/5/2007 DUI Subsystem LuaMutex blocked (TDUTabSheet.ActionToControls)
11:49:22:429 1/5/2007 DUI Subsystem LuaMutex blocked (TDUTabSheet.SetCommand)

9)

all my X10 devices, I unchecked 'save device condition'

but when I restart girder, the previous state is still remembered

Marcel

[mhwlng]

10)

my netremote communication is now very unreliable

I see stuff like this (function called by NR) :

Time Date Source Details Payloads
13:30:11:258 1/5/2007 gettrenddata Script Error: Could not aquire Lua Mutex.marcel v2.0.gml:\TREND\gettrenddata

I've reinstalled 507

Marcel

[Rob H]

1)
I have my own weather stuff, (not using component manager)

and now I see :
Weather callback function error ...ogram Files\Promixis\Girder5\luascript\NetRemote.lua:148 7: unable to unlock mutex for Eindhoven Forecast Conditions

7)

one time, I saw several 100 of this :

Time Date Source Details Payloads
11:41:37:335 1/5/2007 NetRemote NetRemote.SendImageFromURL is deprecated - use NetRemote.SetImageURL instead

I only use this function : NetRemote.SetImageURL ("WORLDMAP",url);



Thanks for those, can you try this version of NetRemote.lua which should fix these two issues

[mhwlng]

you didn't attach anything ?

Marcel

[Rob H]

Oops, sorry, I'd attached it then made some more changes and thought I'd attached it again.

Hopefully it will be attached to this message.

[Ron]

I am off to CES so I won't be able to address these issues before that. I'm very surprised by the crashes you are seeing.

1. Do the crashes happen on a script reset as well?
2. What windows version are you running?
3. Does it still happen if you take out the audiomixer plugin?

[mhwlng]

Rob :

I now see :

Time Date Source Details Payloads
16:57:51:242 1/5/2007 NetRemote Error during call: ...ogram Files\Promixis\Girder5\luascript\NetRemote.lua:172 0: attempt to call method `SetImageURL' (a nil value)

the weather/mutex error is gone...

Ron :

1. Do the crashes happen on a script reset as well?

yes (also after update netremote.lua)

2. What windows version are you running?

vista rtm (507 works ok)

3. Does it still happen if you take out the audiomixer plugin?

this plugins is not enabled (has never been enabled).

Marcel

[Ron]

Can you disable some plugins to try and narrow down the crash area. Start with the transport plugin.

Do the crashes produce an bug report. How do the crashes happen, does girder sit around for a while and then appears to hang and the dies?

[mhwlng]

Do the crashes produce an bug report.

no, just a standard windows dump

How do the crashes happen,

stop girder or press f11

does girder sit around for a while and then appears to hang and the dies?

I suppose so, it takes 10 seconds or so before I see the windows crash message ???

[mhwlng]

I've started girder without any gml file loaded.

it still crashes at shutdown

If I try to disable any plugin, girder crashes...

If I stop girder, I see immediately in the log display

girder :scriptdisable
girder :girderclose

then a few seconds later (maybe 3) girder crashes...

Marcel

[Ron]

There might be an error log (bugreport.txt) in your Girder directory. Can you check?

[Rob H]

Here's another version of NetRemote.lua

[Ron]

Also please try the attached girsystemevents.lua. Please test separately from Robs changes so we can determine which modification fixed the troubles.

[mhwlng]

There might be an error log (bugreport.txt) in your Girder directory.


nope...

Marcel

[mhwlng]

replacing girsystemevents.lua. (or netremote.lua) does not fix the crashing at shutdown...

Marcel

[mhwlng]

the crashes seem to be related to

plugins\serial.dll

(also see my earlier discussions with Rob about similar problems in 507)

Marcel

[Rob H]

Has the latest version of NetRemote.lua fixed the SetImageURL problem though?

[Rob H]

For what it's worth, I'm also seeing the same shutdown problem when using a Component that creates a serial device.

[mhwlng]

Has the latest version of NetRemote.lua fixed the SetImageURL problem though?


yes, I don't see any obvious errors in the log or console anymore



For what it's worth, I'm also seeing the same shutdown problem when using a Component that creates a serial device.


yes, but the modification that you suggested for 507 doesn't work anymore

[Ron]

alright. Let's try this. The transport plugin includes the full serial functionality. However for compatibly reasons we did not want to pull that until we had the transport replacement tested.

Put the attached file into your luascript directory, then in the init.lua of the serial plugin (plugins\serial\init.lua) include this file at the top (include('serial')).

Again this is not tested you might have to fudge a little.

I am packing up to leave for CES so I have limited time to help out, sorry.


... I'll have to do some work on the serial plugin,.. just a sec...

[mhwlng]

I added require('serial') to serial\init.lua but I don't notice any difference
same crash...

Marcel

[Ron]

as i said, wait a second...

[Ron]

stop Girder

keep a copy of your old serial.dll and init.lua

serial.dll goes in the plugins directory
init.lua goes in plugins/serial
serial.lua goes in luascript directory.

Start Girder and keep fingers crossed. This is completely untested.

[Ron]

forgot the updated transport plugin goes in plugins\

[mhwlng]

well...

it doesn't crash at shutdown

but I now see this :

Time Date Source Details Payloads
19:33:47:648 1/5/2007 Serial Time to open serial devices was 666.23355761696 ms
19:33:47:512 1/5/2007 Serial Could not open CallerID Dynalink on comport 2 error unknown
19:33:47:485 1/5/2007 CallerID Unable to intialize modem

then in plugins\serial my modem has disappeared from com 2

I add it again,

in the log, I see
Time Date Source Details Payloads
19:36:50:766 1/5/2007 CallerID CallerID Enabled

but after a restart, I get the same problem as above)


I also regulary see this in the console :
update Status called!

[Ron]

not sure what that error was but see if this version fixes it.

[mhwlng]

yes,

the caller id modem is ok now....

but now the component manager can't enumerate the available serial ports anymore so I can't set up the w800/rfxcom...

also, when I installed 508, I lost my xAP functionality and half my DM X10 devices didn't work properly anymore (DM stuff, X10 stuff was ok)...

reverting to 507 didn't fix either problem....

So, I deleted all cfg files and am trying to reenter the data (but can't because I can't select a serial port for the W800/RFXCOM device)

and I have no idea how to diagnose the xAp problem..

Marcel

[Ron]

xap did not change from 507 to 508. It did change from 506 to 507. I have no time left to help on any of this. Maybe Rob can have a look.

[Rob H]

As a temporary workaround for the setting com port problem you should be able to do this from the Lua console using W800RF32:SetComPort(number) (substituting the correct name of the w800rf32 component). It should only be necessary to do this once.

If Ron doesn't have time to do this I'll see what I can do to fix this tomorrow (if it doesn't require changes to the transport DLL).

No idea about the xap problem I'm afraid.

[mhwlng]

modem stuff is still problematic (not every startup)

Time Date Source Details Payloads
20:38:54:259 1/5/2007 CallerID Unable to intialize modem


Serial Error: ...gram Files\Promixis\Girder5\/plugins/serial/init.lua:143: attempt to call method `UpdateStatus' (a nil value)
stack traceback:
...gram Files\Promixis\Girder5\/plugins/serial/init.lua:143: in function `UpdateStatus'
...gram Files\Promixis\Girder5\/plugins/serial/init.lua:155: in function `Close'
...gram Files\Promixis\Girder5\/plugins/serial/init.lua:346: in function `Close'
...romixis\Girder5\/plugins/serial/calleriddynalink.lua:82: in function <...romixis\Girder5\/plugins/serial/calleriddynalink.lua:33>
(tail call): ?
...gram Files\Promixis\Girder5\/plugins/serial/init.lua:1646: in function `DeviceInitialize'
...gram Files\Promixis\Girder5\/plugins/serial/init.lua:1507: in function <...gram Files\Promixis\Girder5\/plugins/serial/init.lua:1503>

[Ron]

not sure why it's not calling the stub, but feel free to comment out the lines containing

self.Serial:UpdateStatus ()

line 143 and 865

Revert to a 505 or so XAP plugin for the time being.

[mhwlng]

I think there is something wrong in 508, related to all the configuration files.

to reproduce : just delete/move/rename all the .cfg files and try to enter a location or change some sunclock setting......

p.s. I tried to install 506 to diagnose the xAP problem (I think it was working ok in 507, before I installed 508????) but it immediately crashes, no bug report...

I'll try to use an older plugin in 508

Marcel

[mhwlng]

installing a 506 xap.dll in 508 immediately crashes girder at startup (no bug report)

[Ron]

Mike made a boo-boo with the setting thing. I'll try to push out an full update for that before I leave.

[Ron]

go to 505. 506 had the broken xap.

[Rob H]

Are you still having problems with the component manager enumerating ports? That seems to work here.

[mhwlng]

Are you still having problems with the component manager enumerating ports? That seems to work here.


doesn't work for me (with all above changes!!),

I changed init.lua to return a fixed list

function serial.GetAvailablePorts () -- does not include already open or used ports, even if G has them open
--local t = serial.EnumUsingGetDefaultCommConfig ()
local t = {1,2,3,4,5,6,7,8,9,10}
....

now it works ok

Marcel

[mhwlng]

the xAP problem was solved by replacing xap.lua with the 505 version (xap.dll was ok)

Marcel

[mhwlng]

I still see this at startup (not every time)

Time Date Source Details Payloads
21:19:54:886 1/5/2007 Serial Time to open serial devices was 662.26992536761 ms
21:19:54:738 1/5/2007 Serial Could not open CallerID Dynalink on comport 2 error unknown
21:19:54:728 1/5/2007 CallerID Unable to intialize modem


Marcel

[Rob H]

Not sure what the problem can be there. I don't have access to a Dynalink which makes life a little tricky, but I'll be giving the new transport plugin a good workout over the weekend.

[Rob H]

Actually, looking at the code, it does use self.Serial:Read() rather than using a callback which is not really the currently recommended way to do things. That might be the source of the problem

[mhwlng]

I don't think the modem (used for callerid) is the problem, to me it looks like the opening of the port that's problematic (it's a regular com port, not a usb com port)

at girder startup it's connecting to several com ports at the same time

I removed the modem from windows as well, that didn't make a difference.

I don't use the g5 callerid code, but my own (which also doesn't use a callback)
attached the dynalink serial device

Marcel

[Ron]

Note: the read functionality should not be used. Always use the callback mechanism.

[mhwlng]

ok... I will redo my serial device code and try again...

note that your CallerID.lua and irman.lua work the same...

Marcel

[Rob H]

It's hard to see how the Open can actually fail


Open = function (port)
local x = transport.New(transport.constants.transport.SERIAL )


local z = getmetatable ( x )
z.UpdateStatus = function ()
print("update Status called!")
end

x:Open(port)
x:UpdateStatus ()
return x
end,

unless transport.New can fail that is.

[Ron]

the new should not fail, unless this is not a Pro version of G. Put some debug out puts in there to determine what is going on.

[mhwlng]

I haven't tried the revised 509 yet, but I redid my callerid plugin, as you suggested, and now it's ok....

new version attached...


Marcel

[Rob H]

Great, glad to hear it.

[Ron]

509 are the collected fixes from this thread. So it *should* work too.

[mhwlng]

yeah, serial stuff in build 509-2 now works ok

but....

in the previous tests I had a different/wrong serial.lua

using the serial.lua from 509-2, now the com port enumeration is ok (as Rob commented earlier)

so I uncommented in init.lua again :
local t = serial.EnumUsingGetDefaultCommConfig ()

I also uncommented :

self.Serial:UpdateStatus ()

and have not seen any errors yet...
(I don't know if those errors disappeared with my new callerid plugin)

Marcel

[mhwlng]

also note that xAP is still disabled in 509-2

you forgot to remove this bit from xap.lua :

if true then
return
end

Marcel

[Ron]

darn, I'll put up a note with the release.

[mhwlng]

I am having some problems with 509 serial stuff now ...

the rfxcom receiver uses IncompleteResponseTimeout to detect the end of a variable size packet :

BaudRate = 4800,
Parity = 0,
StopBits = 0,
DataBits = 8,
FlowControl = 'N',
CallbackType = serial.CB_FIXEDLENGTH,
ReceiveFixedLength = 16,
IncompleteResponseTimeout = 40,
NoResponseTimeout = 1000,
SendTerminator = '',
LogLevel = 4,

in 507, that worked fine, now longer packets aren't properly detected.
I tried some other values for IncompleteResponseTimeout, but can't get it to work properly..

Marcel

[Rob H]

As an experiment to see if it's solely related to CB_FIXEDLENGTH could you try making it CB_TERMINATED, but use a terminator that won't ever exist (if possible)

[mhwlng]

the data is binary, so there is no terminator character that will never happen...

format is

- byte with data size (counted in bits)
- data byte 1
- data byte 2
...
data byte 4..6

(usually) repeated 5 times in a row...


so a 4 byte data packet is sent as 5 bytes with the first byte having the value 32.

I don't think I can use the MARKEDLENGTH1 type because there is no start marker byte...

and if 2 rf devices are sending at the same time (happens regularly), it becomes a mess :-)

Marcel

[mhwlng]

ah, I see that the terminator can be a string, not only a single character...

so I can test your suggestion...

stand by..

Marcel

[mhwlng]

Rob, I switched to this :

BaudRate = 4800,
Parity = 0,
StopBits = 0,
DataBits = 8,
FlowControl = 'N',
CallbackType = serial.CB_TERMINATED,
ReceiveTerminator = "JUSTATEST",
IncompleteResponseTimeout = 40,
NoResponseTimeout = 1000,
SendTerminator = '',
LogLevel = 4,
SendStartByte = "",

makes no difference

5 byte packets are received fine :

32---00100000
100---01100100
155---10011011
8---00001000
247---11110111


7 byte packets are screwed up (worked fine in 507)
i.e. usually, I get a packet with just the first byte or first two bytes (which I can't explain)..

changing IncompleteResponseTimeout doesn't do much, so I'm wondering if any of these settings are actually used now ?

Marcel

[mhwlng]

just to be 100&#37; sure, I reverted to 507 again, with the same component code as above and everything works fine

Marcel

[Rob H]

Looks like there's a bug there then :( We'll have to wait for Ron to get back from CES then as I don't have the sources to the transport DLL.

The only other possibility that I can think of is to use a fixed length of 1 and assemble the packets yourself, but I doubt that it would be worth it.

Out of interest what's the code you're using? Is it substantially the same as the w800rf32, at least as far as the ReceiveResponse method is concerned?

[Rob H]

That's interesting. As an experiment I changed the receive terminator in my LGTV plugin from \r\n to \r and I'm getting incomplete response timeouts when the \n is received.

[mhwlng]

Is it substantially the same as the w800rf32


pretty much the same, see attached :

(note that I'm using id's that haven't officially been accepted by Mike yet)

[Rob H]

Hmm... I notice that it doesn't actually check the value of code to make sure that it's serial.INCOMPLETERESPONSETIMEOUT or serial.RXCHAR, so you could in fact be getting other code values, some of which may include data that wasn't transmitted in the old serial plugin.

[mhwlng]

I had already added some debugging code during my 509 tests and the code returned is 8192 = INCOMPLETERESPONSETIMEOUT (as expected)
and the data is the correct complete packet when the packet size is 5...
and usually just the first or first two bytes when the packet size is 7...

Marcel

[Rob H]

Can you post a console log of the received data?

[mhwlng]

this is what happens in 507 :

5x the same 7-byte packet (power meter)
5x the same 5-byte packet (x10 motion detector)

********* code :8192
48---00110000
0---00000000
240---11110000
2---00000010
132---10000100
0---00000000
2---00000010
********* code :8192
48---00110000
0---00000000
240---11110000
2---00000010
132---10000100
0---00000000
2---00000010
********* code :8192
48---00110000
0---00000000
240---11110000
2---00000010
132---10000100
0---00000000
2---00000010
********* code :8192
48---00110000
0---00000000
240---11110000
2---00000010
132---10000100
0---00000000
2---00000010
********* code :8192
48---00110000
0---00000000
240---11110000
2---00000010
132---10000100
0---00000000
2---00000010


********* code :8192
32---00100000
116---01110100
139---10001011
16---00010000
239---11101111
********* code :8192
32---00100000
116---01110100
139---10001011
16---00010000
239---11101111
********* code :8192
32---00100000
116---01110100
139---10001011
16---00010000
239---11101111
********* code :8192
32---00100000
116---01110100
139---10001011
16---00010000
239---11101111
********* code :8192
32---00100000
116---01110100
139---10001011
16---00010000
239---11101111

stand by, while I reinstall 509

Marcel

[mhwlng]

this is what happens in 509 (same component code) :

5x the same 5-byte packet (x10 motion detector)

where the last packet is weird.
(I don't know if this is due to a real RF transmission error, another test done later, had 5 identical correct packets)

********* code :8192
32---00100000
116---01110100
139---10001011
16---00010000
239---11101111
********* code :8192
32---00100000
116---01110100
139---10001011
16---00010000
239---11101111
********* code :8192
32---00100000
116---01110100
139---10001011
16---00010000
239---11101111
********* code :8192
32---00100000
116---01110100
139---10001011
16---00010000
239---11101111
********* code :8192
33---00100001
116---01110100
139---10001011
16---00010000
119---01110111
128---10000000


should be 5x the same 7-byte packet (power meter)

but.... big mess :-)

********* code :8192
48---00110000
********* code :8192
240---11110000
2---00000010
160---10100000
********* code :8192
4---00000100
48---00110000
240---11110000
2---00000010
160---10100000
********* code :8192
4---00000100
48---00110000
240---11110000
2---00000010
160---10100000

Marcel

[mhwlng]

I just noticed that all the zeroes are missing in the 509 dump (compared to the 507 dump)..

could there be a fixed terminator character of 0 ???
or does the plugin return the data in a c++ string and the 0 terminates it ?

Marcel

[Rob H]

So, all the data is indeed coming in at least. It does rather look as though the incomplete response timeout is just set to a default or something. It might be interesting to try a serial port monitor to see what the exact timing of the data is.

Guess we'll have to wait for Ron for a resolution.

[mhwlng]

I think the missing zeroes is the problem, not the incomplete response timeout

(see my comment above)

Marcel

[Rob H]

Ah, so it does - don't know how I missed that. I think you're probably on to something there. A C or C++ string may well be involved somewhere.

[Ron]

which parser (callback) is involved ?

[Ron]

Looking at that script it looks like a fixed length parser, is that correct? I don't see where a 0 character would mess this parser up though. What is the data that is coming in according to 507 or according to the documentation?

[mhwlng]

I'm not sure what you need to know, Ron ?

the code is pretty much the same as Mike's W800 code...

everything works as it should in 507.

you can see few few posts back, the data as it should come in (according to the documentation and works fine in 507) and as it really comes in in 509-2

a packet ends at the first zero it encounters... so this looks to me like a c++ string termination issue...

Marcel

[Ron]

What callback type are you using in the script. Is it indeed the FIXED length callback with 16 bytes as its length?

[mhwlng]

correct, same exact code as Mike's W800 component...
note that the messages are in fact variable length (5..7 bytes)

Marcel

[Ron]

40 ms timeout is quite short, can you try increasing this to say 100ms? See if this still happens. I can't at the moment find a reason for the 0 character to be at fault.

[mhwlng]

I've already tried many different permutations of the timeouts, but get no improvement (as if setting the timeout has no effect)....

[Ron]

okay. I will use the loopback transport to simulate the RFXcom device.

[Ron]

alright, I think I found it.

[mhwlng]

it's ok now.. thanks..

Marcel

[mhwlng]

hmm...

I've now got problems with another serial plugin (worked fine in 507)



local device = serial.Classes.Queued:New({
Name = "Kettler Treadmill",
Description = "Kettler Boston XL Treadmill",
BaudRate = 9600,
Parity = 0,
StopBits = 0, -- 0 = 1 stopbit.
DataBits = 8,
FlowControl = 'N',
GlobalName = 'Kettler',
IntraCharacterDelay = 0, --delay between characters
CallbackType = serial.CB_TERMINATED,
ReceiveTerminator = '\r\n',
SendTerminator = '\r\n',
IncompleteResponseTimeout = 2000,
NoreponseTimeout = 2000,
LogLevel = False,

Initialize = function (self)
self.MyMutex = thread.newmutex ()
self.Serial:RxClear()
return serial.Classes.Queued.Initialize (self)
end,

RequestStatus = function (self)
self.MyMutex:lock ()
self:SendCommand ("ST")
while self.ResponsePending do
win.Sleep(50)
end
local reply = self.Reply
self.MyMutex:unlock ()
return handlestatusdata (reply)
end,

ReceiveResponse = function ( self, data, code )
if math.band (code,serial.RXCHAR) > 0 then
self.Reply = data;
else
self.Reply = nil;
end;
serial.Classes.Queued.ReceiveResponse (self,data,code)
end,
}
)
serial.AddDevice (device)


receiving small messages works ok
ACK 10 13 works ok,
the data I see is just ACK (without lf\cr as expected)

but bigger messages (about 40 chars) now cause incomplete response timeouts (increasing the timeout has no effect)
and the data string in ReceiveResponse is terminated with ascii 10 13...
the lf\cr characters should not be there...

there are no nulls in these messages

Marcel

[mhwlng]

ok... I've found the problem

apparently the ACK messages end in 13\10 and the bigger messages end in 10\13

so it is normal that ReceiveTerminator = '\r\n' only works for the ACK messages...
(just using ReceiveTerminator = '\r' or ReceiveTerminator = '\n' also doesn't work b.t.w)

The strange thing is, why it was working fine in 507 ?

anyway, I've changed to the same trick as the w800 plugin..

CallbackType = serial.CB_FIXEDLENGTH,
ReceiveFixedLength = 100,

and then use the incomplete timeout...

that seems to work ok

Marcel

[Rob H]

Not sure I like the use of the win.Sleep in there.

Does RequestStatus have to be synchronous?

[Rob H]

In 507, I think I'm right in saying that it was treating the characters of the receive terminator as alternates rather than a sequence.

[mhwlng]

In 507, I think I'm right in saying that it was treating the characters of the receive terminator as alternates rather than a sequence.


ah, ok. that explains it..



Does RequestStatus have to be synchronous?


unfortunately yes...
I've actually got 10 or so similar functions
do you have a better way to do this ?

marcel

[Rob H]

I'd just try to avoid making them synchronous and either trigger events when the response came in or use a publisher.

You might be able to use coroutines, but I've not really investigated those very deeply.

[mhwlng]

I have 10 or so functions that send a command to the device and wait for a reply (could be ack/nak/data/nothing)

some of these functions are called from a thread, others from communication server events...

e.g. this starts the whole thing off (heartrate controlled treadmill) :



if (Kettler:RequestReset()=="ACK") then
win.Sleep(100);
if (Kettler:RequestCommandMode()=="ACK") then
gir.LogMessage('TreadMill', "Starting treadmill", 0)
Kettler:RequestSpeed(minspeed)
Kettler:RequestIncline(minincline)
thread.newthread (PollData,{})
else
gir.LogMessage('TreadMill', "Could not switch to command mode", 1)
end
else
gir.LogMessage('TreadMill', "Could not reset", 1)
end
else
gir.LogMessage('TreadMill', "Error Communicating with treadmill", 1)
end



sometimes I need to call >4 functions in a row, one after the other, all depending on the reply of the previous function...

using events or a state-machine in ReceiveResponse is theoretically possible, but would make it much more complex (for me at least :-) )

I don't know anything about coroutines....

Marcel

[Rob H]

Well, as long as it works :)