Serial plugin receiver issue?

[Mark F]

Which version of Girder are you using? (So I can try to re-create this)

EDIT: What are the transmit properties, baud, etc. of the Cass?

Thanks.

[Mark F]

I just unpacked the 3.0.1 source and there is NO error reporting in that version. This means received events are dropped and you don't know about it.

The same was true with 3.0.

There are three things that can cause this error message in 3.0.3:

If a different serial device is being enabled/disabled when the last character of the event comes in.
If more than 5 seconds elapses while the received event is pending.
If the amount of data causes an over-run in the event processing.

For number 1, are you using the enable/disable commands built into the serial plugin in the multi-group that causes these responses? If so, this is easily fixable.

For number 2, if the multi-group that sends commands to the Cass is more than 5 seconds long, this could be the problem. If we find this is the problem, I will add commands for "enable/disable receive" as you suggested. I may do this in the next release anyway as this is a really good idea. :)

Number 3 is not possible with a 64 byte data record.

Before fixing this, which I will, I'd like to track down which of the above is causing it. OK? :) I want to make sure I'm not treating a symptom instead of the problem.

[Mark F]

I think I've found it. What I have is a classic "deadly embrace". :oops: I have one thread waiting for an object owned by another and vice versa.

The event thread of Girder gets an event and goes through all the commands in the multi-command. One of those causes data to come from the Cass. This makes MY thread try to send Girder an event. When my thread does this, it must own the "Common Data" object to guarantee a different thread doesn't mess things up. However, the event thread is busy so my thread blocks waiting for the event thread while holding this common data object. What is the event thread doing? It is trying to send data to the com port. This data must be passed to Girder to be parsed for register and variable substitution strings. In order to parse this data, the event thread must own the common data object. Classic.

Probably more information than you needed but at least I know WHY it is failing.

Let me fix this tonight and get you a better version tomorrow.

[Mark F]

This is what I think you said in your latest post. :)

You have a multi-command. This multi-command disables a group which does the parsing of serial data. It then sends a bunch of commands which may cause the reception of serial data. It then re-enables the parsing group. Any serial data received during the multi-command is processed and parsed.

If this is true, here is the answer. :)

Girder event processing is done on one thread of execution. Think of the multi-command as a big single command which executes from start to finish with nothing in between (including processing other events). Your multi-command disables/enables the parsing group, group A, without letting the events for group A be processed (discarded). When your multi-command finishes, group A is enabled and there are events waiting for it.

In this case, the disable/enable in the multi-command is doing nothing for you. You said this is OK; but, in case you'd like to discard this data, you need to leave group A disabled at the end of the multi-command and re-enable it after all the events have been discarded.

HOW TO: Move the "Enable group A" command outside of the multi-command. In it's place, at the end of the multi-command, create a user event command. Learn this user event as the trigger for the "Enable group A" command you just moved.

What this will do is enqueue the user event AFTER all of the received serial data in the event queue. After the serial data is processed (and thrown away) group A will be re-enabled.

If I didn't understand what you meant, please tell me and I'll try again. :D

By the way, I just sent the new serial plugin to your Sun account. If you'd like me to send it somewhere else, PM or E-Mail me. I haven't put in the disable/enable receive commands yet. Only fixed the bug.

[Mark F]

Yes, I was talking about the UserEvent plugin. I didn't mean to be cryptic. :)


... we enable it by executing myevent to goto a group which clears the data and enables the group for parsing again.
Almost. Use the UserEvent plugin to inject an event into the stream and this new event will be placed at the end of the current event stream. The serial events which were caused by the previous commands should be in front of this newly injected user event. Girder will try to service the serial events, but the parsing group is disabled so they get thrown away. Eventually, the injected user event gets processed and it causes the enable group command ot be triggered.

[Mark F]

I have sent the latest version (3.0.4) to Ron.

Changed/new stuff:
Fixed deadlock between event and command threads

This will show up on the download page as soon as Ron can get it there. Please be patient.

Rick - This is exactly the same as the code you have but re-badged to remove the Beta designation.

[Mark F]

That is weird. :-?

As usual, I can't reproduce this. What other plugins do you have running? Which version of Windows? As a curiosity, how fast is this PC?

Could you also help me with a step by step description of what you do to see this? Is it long and involved or do you do these three things and BAM!

[rickd]

I am receiving several events via my Serial port from the Cass 2. Every time I do something it returns 64 bytes of data.

However it seems to have a problem with situations where several events are being returned. I get an error form the Serial plugin saying unable to send data to Girder.

I am disabling the "On serial Event group" in my tree to stop girder jumping out while I send several commands via RS232 to my Cass.

However this erro is still popping up and the event queued seems to come thru after I click ok on this error. I think this problem was not there in version 3.0 but has come about in 3.03.

I am going to do more testing like doing a port enable before sending each command.

My settings under receiver are time out 250, buffer 214.

It is a 64 byte fixed length string.

Mark any ideas....it could be related to the issues driving the requirement for queuing but I am sure this was not there before....

One option that would be nice would be disable received data while allowing commands via RS232 to be sent this way it would prevent an overload of received serial events. The thing is though that the Cass is only sending one event frm what I can tell....

Thanks Rick

[rickd]

Mark thanks this all makes sense I suspect it's either 1 0r 2. It is 3.03 on 3.12e of Girder.

My multigroup is hanging up for a few seconds and then it gets the error. Then the serial data arrives intacted after I click ok on the error and the group completes fine. The group sends out several serial commands. These will trigger a status return and I think it is the status return causing the hang up.....I disable the On serial event group so as not to interrupt the processing of these commands until they are complete then I reenable the receive group so it can update the status variables I track.

I am enabling the other comport but thats happening independent of this group maybe I should check it as it is a recent addition. I am using enable only on another device (barco) to solve another problem I had of only geting 7 bytes instead of 8 some sort of timing error. By enabling the comport before requesting status it seems to fix it. This is just after sending a change input command which returns data by default.

Testing the event on the Theta Cass comport it occurs everytime so it should be easy to figure what this issue is so anything you want me to add to track it down let me know and I can test it for you.

I am going to see if enabling the comport prior to sending commands works.

Actually since there are up to 12 serial events sent it is possible that 12 returned status events are being fired back would that cause an overrun?

Looking at the log though it only seems to get one.
Cheers Rick

[rickd]

Thanks Mark I just did more testing and using enable seemed to fix it using test command but as soon as I used an ir event to kick it off it fell over again. So it had to be something like you described.

Probably explains why I have been going in circles to work around this problem for the last few weeks.

Really keen to see you put in disable receive at some stage :)

Look forward to testing the new version cheers Rick

[rickd]

One bit of behaviour I find strange is that if you disable your receive serial event group (which does the parsing and tests for conditions to drive other events ) while doing other stuff (cause you don't want it interrupted) then when you finally complete these tasks and re-enable it the event from the serial port is still there and it gets processed at this point not ignored. It's not a problem I like it this way but curious as to whether it supposed to work this way and whether that could cause problems?

Cheers Rick

[rickd]

THanks Mark I have done a quick test and the new file seems to work great. As for your explaination it is great so in effect a multigroup has to complete before other events outside of a group can be processed.

Userevent you speak of above I presume is an event using your other plugin "user event" so that at theend of my group where onserial event or Group A as you call it is disabled we enable it by executing myevent to goto a group which clears the data and enables the group for parsing again.

In terms of dumping the data or waiting serial event out of the queue without parsing the data in it...... can I set up a command which takes pld1 or pld2 before re-enabling the parse to clear this data or event prior to re-enabling the parse group...... so that it does not go thru the receive or parse group under certain circumstances and cleans the event queue in this respect?

THanks for the great service and plugin by the way this is getting very powerful. Being able to turn on my projector and pull my screen down based on input select on the cass is very nice. Having Volume and status onscreen display for the Cass while the HTPC is running is nice too. Turning offthe projector and pulling the screen up when you simply push standby on the front of the cass or via remote is nice also now it all works of course. Selecting the right input on the projector based on the input on the Cass is another goodie.....I guess I could go on and on :D

Cheers Rick

[rickd]

Great thanks Mark .....the serial plugin is still going strong no more problems so far.

Cheers Rick

[rickd]

Mark

I think I may have found another small bug.....when I use enable serial port to reset the port if I try disable and then enable all devices using F9 girder stops responding and it typically crashes. I took these commands out and the problem disappears.

Note I am not disabling the port first just using enable.

Cheers Rick

[rickd]

Mark I'll do some more work on it I just cleaned my reg as it was a mess so I need to retest it.......I have an 850Mhz duron and am beginning to think it's a little lite with my Girder file though 3.2 may improve things.

I was getting window does not exist on my Theatretek group intermittently I am not sure what is causing that either. I will post on this .

[rickd]

Problem solved it might have been caused by wrong ir device setting.

All stable now......guess I'll have to go to 3.2 soon :wink:

Rick