¿ªÔÆÌåÓý

Locked Re: Locobuffer locking up from data overload?


 

Steve,

This reply from Billybob explains a lot - why you were getting the funny flashing, why there was no check box for software flashing. And, why you were under the impression that CATS preferred that the fourth aspect be dark. I was scratching my head on that last one because I don't remember making that recommendation (though it is the most versatile of the four possible fourth aspect configurations, it has its drawbacks). I figured the recommendation was posted somewhere and I either forgot it or missed it.

You should be able to create JMRI signal heads using turnout commands and as long as you don't change their names, you should be able to leave your CATS panel unchanged.

Rodney
_________________________________________________________________________________________
Steve,

This behavior is likely entirely consistent with JMRI's basic behavior for JMRI "signal heads" which are configured as controlled by an SE8c.

JMRI does not have support for any SE8c mode other than "fourth aspect dark".

When you change the SE8c mode to "fourth aspect flashing red", JMRI doesn't know that. It _assumes_ that it must "manually" flash the signal head. So JMRI alternately sends the turnout command for "RED" then the turnout command for the "Fourth Aspect", which it thinks is "dark". But the SE8c is _independently_ flashing the RED LED in the head, using its own timings. So you will get a JMRI phase of "RED" (from the "RED" turnout command) and then a JMRI phase of "Fourth Aspect". Exactly what you see at the LED depends on the SE8C flashing "phase", so you should expect to get odd patterns on the Red LED.

I cannot envision any way to get around this problem without changes in JMRI's signal code.

Regards,
Billybob

Join [email protected] to automatically receive all group messages.