ADICON Support Forum Applied Digital, Inc.
Page 1 of 1 1
Topic Options
#22090 - 08/31/10 01:15 AM Contractor's Toolbox
bvnoldguy Offline
journeyman


Registered: 07/20/10
Posts: 50
While discarding about a half dozen architectures for my pxa_client (part of my Python project), the idea of a contractor's toolbox hit me.
---
Imagine a GUI framework where you select from an extensible template and plug-in library the features you want. The chosen templates are customized using their GUI plug-ins. Then, the "generate" button is pushed and you have deployable tablet, Windows, and MAC GUI's along with the C-Max .PGM file for the Ocelot. No programming.
---
The framework and template/plug-in facility is a clone of the one my grandson and I built to generate Race mods for Valve's Source Engine. If you don't know what this is, ask any hardcore gamer.
---
The GUI generator is what I need for my pxa_client project.
---
The C-Max .PGM generator uses a Python reincarnation of the DMX assembler I built for the Hyena 2002 project. This re-incarnation I will call C++Max which is more representative of what it really is. My current PGM file is generated from 41 independent blocks of code. I can modify any one of them without compromising the others. And by modify, I include the addition to or dropping of the number and use of variables & timers. Also, physical rewiring of the Ocelot and it's outlying controllers can be accommodated in the device definition blocks, whereupon, the dependent blocks automatically use the new device addressing as do the GUI modules. This has been working for 8 years - through 65 generations of the C++Max code.
---
The automatic GUI adaptation is courtesy of my pxa_server project which is in it's 3 month burn in test. I am looking for no crashes in 3 months of 7 x 24 hour operation - which is why it is running on the CentOS distribution of Red Hat's Enterprise Linux and not Windows.
---
The core of C++Max is my BigMac, which is already converted to Python (BigMac is basically written in BigMac) and has already been used in a number of my other projects.
---
BigMac: Bruce's Implementation of a George Mealy Automaton Compiler. Ref: Mealy, George H. (1955). A Method to Synthesizing Sequential Circuits. Bell Systems Technical Journal. pp. 10451079. A Mealy machine is a technique for describing a finite state automaton, which is explained in the Wikipedia. It is also a means of describing and implementing a regular programming language a'la LEX and YACC, familiar tools to compiler writers.

Top
#22129 - 09/25/10 06:29 PM Re: Contractor's Toolbox [Re: bvnoldguy]
bvnoldguy Offline
journeyman


Registered: 07/20/10
Posts: 50
Things look promising. I intend to use the same kind of XML tarball that OpenOffice and Microsoft Office 2010 use.
---
How I imagine it to work:
=== framework is packaged with Ocelots / Leopards
- Contains Windows, Mac, Linux, Android, Chromium, iPhone, and iPad support (wiFi, G3 & G4)....
- C-Max, as is, is a critical "framework" part.
=== Suppose there is a 4 zone HVAC plugin package then:
- HVAC4Z ships with 4 temperature bob cats and an SECU 16 (3 points for energy source mode and 4 for zone control). SECU wiring is static. IE point 2 is "demand heat".
- there is a deployment configuration tool which allows the installer or contractor to inform the software configuration as to the module addresses (No reason not to support multiple HVAC4Z packages :-). The "deployment tool" is for both office and/or in field use. Needs some discussion.
- C++Max is not used, it is a development tool. It packages up discrete functionality - a sort of "super snippet" which encapsulates an expandable list of PGM, Python, Java, etc. code that share a common symbol set.
===
My pxa experiments inform me that there can be no practical separation of the PGM and Python code since they must share a common symbol set. The IP (CPUXA/IP) tokens are not modified by deployment issues. The Python wxGlade symbols are constrained by the C++Max PGM symbolics that pertain to the common, shared functionality.
---
The final, physical, VAR's, TIMER's, module points are not known until the deployment configuration is known. Dynamic assignment is used for VAR's and TIMER's. The deployment configuration tool will have to complain until the module/point, X-10, and IR addresses are resolved. Same is true for static set-points.
---
The C++Max language does not distinguish between X10, IR, and module/point. Device binding can be deferred until deployment time. The 2002 D-Max language already has this capability.
---
In short, the HVAC4Z package can use IR in one deployment and X10 in another - without modification. Sorry, no workaround for actual temperature sensors and a physical HVAC system :-)
===
FYI: The pxa experiments reveal that a radio_box can be used for both control AND status feedback for functionalities that have more than two states. My HVAC and water-feature systems now use this technique.
===
My business is demanding more, and more, of my time. I can build and publish the framework and tools that I can personally use and test locally. The embellishments will require some help.
---
Programming is a team sport.

Top
#22147 - 10/05/10 07:05 PM Re: Contractor's Toolbox [Re: bvnoldguy]
bvnoldguy Offline
journeyman


Registered: 07/20/10
Posts: 50
For status on C++Max see the python thread.
Top
#22154 - 10/11/10 11:05 AM Re: Contractor's Toolbox [Re: bvnoldguy]
bvnoldguy Offline
journeyman


Registered: 07/20/10
Posts: 50
Note: major progress on the guts. See my Python thread.
---
Have been working on the design. It's exposing a lot of considerations - specifically the separation (isolation) of generic and portable code for deployment specific code.
---
The original D-Max environment allowed for this, but did not go so far as to exploit it. C++Max will. C++Max "encourages" the separation of "input fold-in" and "output fan-out" from the core (portable) CPUXA code.
---
Fold-in - an optional, deployment specific, merge of diverse inputs into the single input needed by the core code.
---
Fan-out - an optional, deployment specific, forwarding of an output to multiple devices and to input of other portable components.
---
The following "example" of a component's interface is my current thinking. The design exercise has really opened my eyes to further PXA GUI extensions. PXA is not required, but is definitely leveraged. C++Max will be the same.
---
The Hyena project (D-Max and WinLepard) was CPUXA code centric. The symbolic names were generated from the CPUXA code and then exploited by the GUI.
---
C++Max will be interface centric - especially the human interface (HID). These symbolics will be generated first, then the CPUXA code will "exploit" the established interface.
---
Note: This is an extract from a seven page "sense of direction" working document for the C++Max portion of the ADICON_Panther project. A component definition as if done as an ini file:
The first token assigned to a value is always a keyword. Examples: "boolean", "state", and "analog".

[inheritance] {optional}
FirstComponent = variant {automatically includes the CPUXA code blocks associated with this variant of the component}
SecondComponent = variant

[Input] {used for non PXA input}
input_name = boolean name {a boolean input CPUXA resource}
input_name = state then a space delimited list beginning with the Var name followed by an enumerated list of the expected values
input_name = analog name range {name- input resource providing the values; range- the number of values, probably 256 (0..255)}

[Output] {used for non PXA output}
Output_name = boolean name {output resource}
Output_name = state then a space delimited list beginning with the Var name followed by an enumerated list of values
Output_name = analog name range {see input}

[pxainput]
WidgetName = button Request-Symbolic
WidgetName = radiobox followed by space separated Request-Symbolics beginning with the GUI zeroth entry.
WidgetName = slider min-value max-value
WidgetName = spinbutton {the range is automatically scaled and offset to match}
WidgetName = spinctrl

[pxaoutput] Note: the same widget name can appear under both input and output
WidgetName = indicator Resource-Symbolic
WidgetName = button Resource-Symbolic
WidgetName = radiobox space separated variable-name followed by enumeration symbolics that begin with the zeroth radio button.
WidgetName = gauge min-value max-value WidgetName = analog Resource-Symbolic followed by the string with % scaling numeric substitution definition.
WidgetName = state followed by sets of pairs [received-string substitution-string] followed by the % substitution string. I really don't like this. I used it in the VB WinLeopard GUI. This is really a choice of last resort.

[pxamodules] {there can be more than one wxGlade frame in the component}
wxGlade = name of wxGlade generated code. It is the name of the wxg file and the prefix used for the generated Python code (_wx.py). A Python module {_gui.py} code will be created to animate the _wx.py code.
Python = names of additional Python modules to be included in the _gui.py module. The design logic for this is in work.
---

Top
#22155 - 10/11/10 07:40 PM Re: Contractor's Toolbox [Re: bvnoldguy]
bvnoldguy Offline
journeyman


Registered: 07/20/10
Posts: 50
Latest thinking:
- I've completely separated pxa components from cpuxa components
- I've separated the pxa support code from the C++Max code. PXA becomes an optional plug-in. Standardized hooks, API and all that jazz.
- ADI leopard support could be added via a plug-in. Maybe somebody could develop a Home-Seer and the like plug-ins?
- replaced deployment specifics (wiring, fold-in, and fan-out) with definition files (no cpuxa code required)
- really increased the requirements of the pre-processor to
-- resolve all component interactions
-- generate, on the fly, the cpuxa code to glue the components together.
-- to dynamically build the list of blocks (files) needed for a deployment.
---
Why? I can make ALL cpuxa code recyclable. With a sufficiently large tool set (HVAC, security, irrigation, ...) there should be no need to use C-Max or C++Max to develop any code.
---
Already, I can build PXA Python modules without any human contact with the code. I am just extending the approach to the cpuxa (.PGM) code.


Edited by bvnoldguy (10/11/10 09:15 PM)
Edit Reason: added Leopard support

Top
#22163 - 10/13/10 02:08 PM Re: Contractor's Toolbox [Re: bvnoldguy]
bvnoldguy Offline
journeyman


Registered: 07/20/10
Posts: 50
The C++Max compiler is done - see Python thread.
---
Latest thinking:
- The C++Max UI and language preprocessor is taking shape as an Integrated DEPLOYMENT Environment and not as a development environment.
- Supporting pxa as an optional plugin is going to save me a lot of development time.
- This should lay the groundwork for an ADI Leopard plugin, should anyone feel motivated to build one.
- The "sense of direction" document is finished - unless the programming reveals something unexpected. What are the odds?
---
I found a HomeSeer interface CPUXA code block written in Nov, 2001. C++Max compiles it correctly in assembler mode. I have no current means to test it.

Top
#22174 - 10/23/10 04:51 PM Re: Contractor's Toolbox [Re: bvnoldguy]
bvnoldguy Offline
journeyman


Registered: 07/20/10
Posts: 50
The C++Max preprocessor is done and mothballed.
---
Since there have been no responses, I assume that there is no interest. I am dropping this project.
---
This is not a revenue generating project, so I am not going to hire folk to alpha test. Personally, I don't need the C++Max bells and whistles to maintain my automation. The C+Max compiler is good enough.
--- TTFN

Top
Page 1 of 1 1


Moderator:  Dan Smith, Monte G, ADI Tech Support, Guy Lavoie 
Hop to:
Who's Online
0 registered and 50 anonymous users online.
Recent Posts
am pm
by edr
05/05/17 05:25 PM
Shout Box

Newest Members
brigiel, vevevie, zhutree, 416, saiqul
3003 Registered Users
Forum Stats
3003 Members
19 Forums
3999 Topics
23425 Posts

Max Online: 132 @ 11/13/16 10:07 AM
May
Su M Tu W Th F Sa
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31