Prop-AL Propeller Assisted Living
ErNa
Posts: 1,752
There are some efforts underway to create propeller to propeller communication and I am now ready to start unifying different modules I made over the years. A lot of beginning and no end in sight. ;-)
While I use a certain mechanism to communicate from cog to cog, I only had an idea to communicate from chip to chip in a transparent way. I now have implemented a first, still q&d version of such a module and I will present it here in a short.
The goal is to have a modular home automation system, that can solve any kind of task in this direction, (hohoho) but I will start with a simple system to control rolling shutters.
A critical point is the user interface, which has to be simple and effective. There are divers methods, from simple buttons with optional led feed-back to touch screen LCD's. I will start with a simple button interface and show how the process control and communication works.
I am still using CMap-Tools http://cmap.ihmc.us/ as a tool to do documentation, so now and then you will find a link to a website showing a rendered concept map.
This is work in progress, so things may change over time, but I have to start. And start is HERE.
While I use a certain mechanism to communicate from cog to cog, I only had an idea to communicate from chip to chip in a transparent way. I now have implemented a first, still q&d version of such a module and I will present it here in a short.
The goal is to have a modular home automation system, that can solve any kind of task in this direction, (hohoho) but I will start with a simple system to control rolling shutters.
A critical point is the user interface, which has to be simple and effective. There are divers methods, from simple buttons with optional led feed-back to touch screen LCD's. I will start with a simple button interface and show how the process control and communication works.
I am still using CMap-Tools http://cmap.ihmc.us/ as a tool to do documentation, so now and then you will find a link to a website showing a rendered concept map.
This is work in progress, so things may change over time, but I have to start. And start is HERE.
Comments
Ooops: off topic.
Erlend
To your first direction, I was under the impression that someone had already made a communication mechanisim; Beau Swaube in one of his projects.(?)
In your total home automation. will you be needing robots? Hmmmm?
Now I created a first link for the cmap above to the next one. It's just the beginning.
About to communication: The aim is to implement a communication process firstly between COGs in one chip. Then transparently expand this to cover a physical network.My effort does not focus on the physical realization of such a network, but on a method to transfer information in a unified way.
The method to transfer information in a unified way, I have tried a program to provide such a process. On the hard drive, I created
a cluster of "worker" A.I.s that needed to communicate with another cluster of "worker" A.I.s In so tackling this, I had to establish
an "authority" level , similar to the Army's command structure. The programming, of course, was in-volved! A work in progress; but
showed promise because of documentation, diagnostics, and control. Maybe this provides ideas for your structure. (?)
I still use Propeller Tool to develop, as this tool is stable and well known. But I can imagine, that Propeller IDE might give more features to manage the libraries, versions, have includes and different language support: does it make sense to switch to Propeller IDE even if code is no longer compatible to the prop-tool?
What should happen:
At start, the leftmost LED 7 should blink. But blinks very fast, you can not see it ;-)
LED 0 will lit, (for some reason)
If you click button P1, LED 1 will lit up.
If you double click to P2, LED 2 can be toggled
P3 works in touch mode, the state controls the LED.
Double clicking P5 reset all Buttons, but LED 2 is toggled and will not change state.
Enjoy!
However, Trooks and Ron Czapala have done projects,
among others, that may help. I think their style was
modeled after PLC control programming. Thanks.
There are two QuickStart boards connected via Full Duplex Serial (Pin 26/27 crossed) running the same software which is compiled with different addresses for localNode and TN (target node). LocalNode == 1 means Master, the only difference between master and slave is: master is delayed at start a little to allow slave to be ready and master, when timed out, creates a seed token.
Just now the QSButtons-object writes the button state of touch switch 0 to the HUB, whenever this state changes, the mirror object sends the new state to the token ring. The target address is a hub variable "ButtMirr[0]" in the target node ( HubAddress*4+NodeAddress).
The main loop outputs the ButtMirr[0] value to the first LED.
I now can push the button on one QuickstartBoard and shine the LED on another one ;-)
When playing with my buttons object, I realized, I easily can remote control a process running in another node, but there is always the question what a reliable system is: I emit a command, that's it: UDP-like. I set up a connection, safely transfer a command, but did the receiver really do, what I want? So I need a next layer to secure the process. In principle, that never ends.
It seems there is need for a system, that is "save enough". All mission critical actions/states must be reliable, so they are only checked to see, if I am dead. ;-) Other actions should be taken and they report a result when executed. Then I can imagine processes, which just look around to read states of processes, inputs, outputs etc and nothing happens, as long as no exceptional conditions are detected. Heart beat, watch dog, process runtime, etc are instruments to detect those conditions. Temperature measured, ambient light etc allow to check for plausibility of the data.
I now have to install it in the real application and hopefully, the first brick for PropAL is set.
Not really off topic. For low speed applications like a lot of those in home/building automation you could use one or more cogs to execute pasm code from hub memory. A single cog could be executing several tasks semi-simultaneously or sequentially. Of course execution would be very slow when compared to code running in a cog, but then again how frequently do you need to read the temperature, start/stop a blower, or open/close a valve?
One example: During debugging I sometimes change the size of the parameter list. That will lead to a crash if the module has less pointers provisioned that are used. Now I introduces a version returned by the routine and can see, if versions of calling structure and called structure are equal. Otherwise the will be an exception.
Just an remark, on topic.
By the way: experiment replaces accident by mistake ;-)
While in principal there is no difference between checking a variable locally or in a remote propeller, transfered by the mirror, in practice there is a different behavior: the button module, when a button is released, counts the button state down to -500. When pressed, the state is counted up to +500. This allows to check this state and to debounce, introduce a hysteresis or just determine the time of pressing the button. But, as the counter counts up at about 1000 Hz, 1000 state changes are taking place, so 1000 messages of 3 bytes length are generated, what definitely takes time and gives heavy load to the token ring. So I have to find a workaround or a new feature: -Just do not uses state to detect button pressed, only click and dclick. Or: reduce the counting range to +-50. Or: leave the counting range unchanged, but reduce number of changes by increasing counting step, leaving debounce time unchanged. This could be a parameter, so the button module can still be used to count laps, on the other hand, when doing remote control, data rate and resolution can be reduced.