Gabor,
Doesn't it suffice for the hardware and the software to accomplish what I want them to do?
The real problem is that you are trying to force the hardware to do something it wasn¡¯t really designed for. ?Software can¡¯t fix that.
The hardware was designed to detect equipment over a large area ( it is a ¡°block¡± sensor ). ?There are certain optimizations performed by the hardware to handle detection in the area. ?We can¡¯t change that behavior.
What you really want for your situation is a sensor that detects a small area ( sometimes called a spot sensor). ?Optical sensors are the most common type of spot sensor.
For another thing, this is one more reason why I was enquiring the possibility of eliminating LocoNet emulation, i.e. sending CAN messages to CAN reporters. You were saying that a TrafficController interface isn't available for doing this as in CanExample.py. I was surprised to learn that the function reporter.reply(<message>) could still do it without the interface; for this I am unable to? produce messages in the desired form (I almost feel the torments of Tantalus in inferno).
There isn¡¯t a CAN traffic controller involved. ?There is a Z21TrafficController involved.
There are some examples of messages in the tests:
This is java code, not python, so the mechanics of producing messages may differ slightly.
I do not believe the approach you have proposed, because I don¡¯t believe it will have the impact you think it will.
Isn't it planned to make such an interface like the one existing for LocoNet, in the forseeable future?
The difference between the LocoNet ( and XpressNet) connections vs the CAN connection on the Z21 is that Roco doesn¡¯t document a method for sending messages to the CAN devices.
They do not even document a method to set the addresses and other parameters, which forces you to use Rico¡¯s software for those operations.
The methods documented in the Z21 communication protocol only describe the Z21s responses to can based occupancy and RailCom detectors.
Paul
