I am posting this with minor edits but it is what I received from Belgium a while back. When reading this, one should assume that the constraints regarding serial.match likely also apply to any 1-way RS-232 actions that might be running concurrently with your Prontoscript.

Behavioral Differences

Application version 7.2.23 introduces a fix for fast subsequent actions on the same extender.

A side-effect of this fix is a slight change in the behavior of asynchronous operation of a serial port from within ProntoScript.

Previously (application [firmware] version 7.2.22 and earlier), when a non-blocking serial.match(..) operation was not yet timed out, new serial.match() operations would fail (for asynchronously addressed serial ports, this failure is exhibited as a call to an onError handler, the match itself would not throw an exception).

[Beginning with] application [firmware] version 7.2.23 however, performing a serial.match() while a pending serial.match(..) is not yet timed out, will cause the pending match(..) operation to abort, potentially dropping already received data in transit.

Urgh?

That's not good. I guess I'll stick to the blocking behavior or make a scheduler that will handle this.

Thanks Lyndel.

The issue with this (and Lyndel am posting this here rather than in the other thread that talks to a similar theme) that I experience is that if I have, say, component A and B, both using schedulers that monitor different COM ports on the same extender (1 and 2 in my case) I lose data and have no way of detecting this.

I have developed a scenario and shared it with Belgium as it was 100% repeatable and am awaiting their analysis - where code works fine when only one of the devices is polled and fails when they both are. Clearly they should be able to co-exist.

I have worked round it by creating another scheduled activity that marshals the data across both ports sychronously and this works at the cost of a slower response time but means that all code referencing serial ports across a single Pronto needs to call the marshalling code and you cannot use the button mappings. In my opinion the marshalling should be done at firmware level not script level so that code I write can co-exist with code someone else writes.

Mark

Mark,

I agree with you as well. I understand that indeed there are times when firmware must change to properly fix an issue. However, a change that breaks backward compatibility as this has done, even in the interest of a bugfix should at least have had some mention in the release notes.

anyone notice firm keys dont execute visual responses anymore they used to... ie pressing a fitm key used to show a pressed state it no longer does???