> An even better solution would be for the server to actually parse > the TSIP message from the Tbolt that has the temperature reading > and for the server to do the PID algorithm and temperature > control PWM. The temp control code is not that long or > complicated. This method gets net delays, etc out of the > equation. It does add the complexity of how to configure the PID > parameters on the server. >
That's my plan -- once you're done with that code I'll move it to a separate .obj file and parameterize it in a way that'll link to both the cilent and server. It would be possible to send side-channel instructions to the server to tell it how to control the DTR/RTS lines on behalf of a PID loop running on a client. However, the other big reason to run the whole PID loop on the server, besides lag and reliability issues associated with the network link, is that we would otherwise need a way to decide which of several possible clients has the authority to run the control loop. Right now all clients are equal in the server's eyes, and I'd like it to stay that way for simplicity's sake. It would be OK for multiple clients to request different temperatures if they want to, just as we currently let multiple clients issue whatever TSIP commands they want, but giving direct control over the DTR/RTS lines to multiple clients would be asking for trouble. -- john, KE5FX _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
