"Wait" between Serial commands doesn't wait??

[mihooper]

Mark,

Sorry to overload you with requests.....but :D

I am sending two different command strings to the serial port seperated by the Girder Window "Wait" action. The format is as follows:

Send Command1 (to serial port)
Wait (1000 msec..or so)
Send Command2 (to serial port)

However, when I monitor the data sent to the serial port (with Portmon http://www.sysinternals.com/ntw2k/freeware/pmon.shtml) both command strings get queued up and are sent AFTER the wait times out. I can extend the wait several seconds, and nothing is sent to the port until AFTER the wait times out..... This is causing my IRLinc device to get very confused.

Am I seeing this correctly? Shouldn't the "wait" get inserted between commands?

thx

[Ron]

Did you put these commands in 1 multigroup ?

[Mark F]

From left field: You could also try the "Intra Command Delay" in the transmit properties of the serial device. This allows you to specify a number of seconds that must elapse between serial transmissions.

[mihooper]

Ron,

Did you put these commands in 1 multigroup ?
The commands are in the same multigroup because they are a macro. But the commands in the multigroup call seperate commands outside of the multigroup to send the serial data. For ex:
================
Event: ScreenDown (sends serial command on com1 to lower screen)
Event: AmpPowerOn (sends serial command on come to turn amp on)

Multigroup: PowerOn
ScreenDown
Wait (1000)
AmpPowerOn
=====================
When monitoring com1, there is no delay between commands sent on com1 port. But there IS a delay before the next event is executed after AmpPowerOn...... Very confusing.

Mark,
I have tried the inter-command delay, but the 1Sec granularity is a bit large. AND, for some reason doesn't seem to allow my IRLinc to respond between commands (no "ack" 01 00). Let me play with this a bit more tonite.

thx

[mihooper]

Mark,

Could I ask you to try something?

1) Create 2 successive events in the same multigroup.
2) Make each event send a long (15-20 character) string to a serial com port.
3) Monitor the serial transmission (however you do this..... I use Portmon).
4) Next, in sert a "Wait" event of several seconds between the 2 events created above.
5) Now monitor the output to see if there is really a delay between commands.

On my system, the first command is queued up until AFTER the delay, and is sent immediately before the second command, with NO delay between the two commands..... It's almost as if the "Wait" event suspends ANY processing of the Serial plug-in until after the wait period times out, thus delaying the transmission of the FIRST command..

Does this make any sense?

[Mark F]

I understand what you are saying and I'll give it a try when I get home. By the way, it makes no sense and should NOT work that way.

[Mark F]

I tried this out this morning. (after a 14 hour day, I was too beat last night)

I hooked one end of a null modem in one port and the other into another on the same machine and although the two strings appeared at the same time at the port, the timestamps I sent as the strings were 2 seconds apart.

I hooked the null modem between two PCs and the strings came into the second machine with the wait between them.

It appears to be working on *MY* machines though the thread of execution that sends data appears to have a higher priority than the one that is receiving the data when I loop it back.

What version of windows are you using? I'm using '98 on both of these.

[mihooper]

Mark,

Thanks for spending time on this!

I'm running W98SE on my HTPC. I can insert a 5 second "wait" between commands to IRLinc, and experience a 5 second delay before the FIRST command is executed on the IRLinc.

The other potential factor here is handshaking. As you may remember, the IRLinc requires the following send sequence:
1)Raise RTS
2)Wait 20ms
3)Send command
4)Lower RTS

I've attached the IRLinc section of my GML in which I implemented this. Now that you've "enhanced" the lua functions, I've also taken a crack at implementing the same sequence in lua. This seems to have some significant timing issues also (for a later thread).

Take a look at the GML and let me know if you see anything fishy.

Thanks again for your help!! 8)

[Mark F]

I'll take a look, at home, as I get a chance. We're having a crunch here at work so I tend to spend a LOT of hours here.

[mihooper]

By all means....keep the day job!!

Did my GML get uploaded correctly? I'm seeing a "0 Byte" size.

[Ron]

The 0 byte size is a bug in the forum :(

[mihooper]

Ron,

Just a thought.... is there a "wait" equivalent lua function??

Here's my script.

function SendCommandToIRLinc (IRMsg)
--Set RTS
SERIAL_SetHandshaking("IRLinc", 2)
--Wait 20ms
TriggerEvent("Wait20ms",18 )
--Send IR Command String
SERIAL_SendData("IRLinc", IRMsg)
--Wait 20ms
--TriggerEvent("Wait20ms",18 )
--Drop RTS
SERIAL_SetHandshaking("IRLinc", 0)
--Wait 20ms
--TriggerEvent("Wait20ms",18 )
end
(I've been experimenting with commenting out various "waits")

I'm jumping out of the script to insert the "wait" with a TriggerEvent call. Is there a better way by using an internal lua wait function?

[Mark F]

Actually, the TriggerEvent() function enqueues an event which is processed at a later time. It doesn't cause the command to be triggered in-line with the rest of the LUA script.

If you have the WinLUAEx plugin loaded, you can use TIME_Sleep( int MILLISEC ) function.

[mihooper]

Thanks Mark...will try it tonite.

thx

[Mark F]

I should have mentioned before, the TIME_Sleep() is limited to 1000 ms (1 second). Of course you can call it multiple times to get longer values.

EDIT: I'm guessing you already knew this since it is in the readme. :D

[mihooper]

Mark.

WOW! :P

I ditched the "jump from lua to the Girder/wait event- back to lua" by using TIME-Sleep() in WinLUAEx. Now the communications with IRLinc is now behaving as expected!! I am now able to insert predictable delays in the execution sequence (as required by the "picky" IRLinc). I think trying to bounce between lua and Girder events is not good practice if critical timing is needed. Keep everything within the script!

:-? ....and, Yes, I did end up experimenting wtih multiple Time_Sleep() statements to get past the 1sec limit.............but I DIDN'T read it in the Readme (in fact, ...hmmm....I actually can't find it there...) :-?

Anyway, here's my final script:


function SendCommandToIRLinc (IRMsg)
--Set RTS
SERIAL_SetHandshaking("IRLinc", 2)
--Wait 20ms
TIME_Sleep(20)
--Send IR Command String
SERIAL_SendData("IRLinc", IRMsg)
--Drop RTS
SERIAL_SetHandshaking("IRLinc", 0)
end


Just for fun, I've attached the GML group for IRLinc showing the calling functions for stored and learned commands. I've added a new varialbe (Time Delay) which is the time delay between commands. Turns out the Dish6000 needs 200msec between command strings, but my Onkyo volume command needs to be much shorter (when my kids hold down the volume control they want it to move quicly!).

Thanks for the guidance!!

[Mark F]

EXCELLENT!

By the way, direct from the WinLUAEx 1.0.2 readme on the download page:


TIME_Sleep( int MILLISEC )
Stops execution of this script for the supplied number of milliseconds

NOTE: The range of MILLISEC is 0 <= MILLISEC <= 1000 milliseconds (1000 milliseconds == 1 second).

:D :D

I'm glad this is working for you. This home automation stuff is getting intense, eh? ;)

[mihooper]

Mark,


By the way, direct from the WinLUAEx 1.0.2 readme on the download page
...oh that! Yes, I thought you meant the "multiple instances" of the same command to get past 1sec........... :wink:

By the way, did you ever get Firecracker to share a serial port with another directly connected serial device? I've tried disabling Firecracker on com1 and enabling IRLinc on com1....don't remember the specifics, but it didn't work (perhaps a new thread would be appropriate here).

Intense :D YES! and I love it!

[Mark F]

... I thought you meant the "multiple instances" ...
DOH! Maybe *I* should read a bit closer, eh?

I haven't accomplished sharing a serial port between multiple devices. It might work but it would be a lot of work. I'll cheer for you if you want to try. ;)

Enjoy. :D