Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Puck]

I just did a few tests of my own, I won't go into the details here, but you will understand what I did.

A string of ELSE's WILL react as expected under most normal uses.

However, if JUST ONE ELSE starts with a DELAY command, the whole string becomes a bunch of ANDS. All that meet their conditions WILL execute.

FIX THIS X-10!!!

Workaround: If you must start a macro with a delay, and it is part of an ELSE string, place a real command at the start (even a dummy switch).

This explains why in my original Empty ELSE Oddity post, why my macro string didn't work properly when I just added a delay (do nothing) task if a certain condition was met.

[KDR]

Thanks for the tip and workaround Puck

My small little setup has 57 macros and most of them have time delays at the beginning. I do this to help keep PLC traffic jams down since allot of timers are set to the dusk/dawn setting. I use some + 5 - 5 settings in my timers but that doesn't fit my time frame for some macros. This also explains why some of them never seemed to work right with ELSE in them.


"good click"

[ArtClark]

Thank-You very much.  I did a large amount of testing, then saw the same thing.  What is stranger, the macros "Run from PC" do
NOT act this way "All the time"  I'm not detailing this, but the PC USUALLY works correctly while the CM15 doesn't.

This drove me crazy, because my CM15 cannot be told to execute a PLC command as the first macro instruction.  That Fails.

I'm wagering, without testing, That the delay causes the next else to fire?  (Other commands don't).

Puck, I knew you would find this out because I couldn't believe it was always not an else.  Wait till you see the strange PC - CM15
flag responses.  It's all inter-related and beyond what I could ever document.  Two Best bets.  1) You said it - X-10 Fix This...
2) Always Test the operation of else clauses.  I use this irregularity as an advantage as long as it's predicable.

[Puck]

Thank-You very much.  I did a large amount of testing, then saw the same thing.

ArtClark: A BIG thank you to you too. Your observations & tests were very Helpful in figuring this one out. 

As far as X-10 fixing this, well I think we are out of luck. This sounds like an operational bug in the firmware. The micro-controller is a One-Time-Programmable device. Hopefully they can figure out a way to fix it in the SmartMacro software.

The source code of the firmware would be nice to have [nudge, nudge,  ,  ]

[ArtClark]

gee, I little thought.....   Do you think it might be possible to find the low-level data being sent to the CM15 from the PC.

If that Info could be obtained, then the actual code sent for smartmacros could be modified, even if it meant creating a
small program to download Macros and timers directly.  What do you think?  I myself can think of ways to monitor the USB
cable, save the binary dump, and decode, but the amount of work that would take, and decoding that I stink at, would
take a long time. 

Just a thought.  I have the feeling that X-10 will consider this proprietary and never release this type of info.

If they do, the smartmacro fix that is being looked for could be created with a "Post Processor" and then sent to the CM15.
To get really fancy, just "Post" the .ahx file and send to CM15.   

Anyone have good information sources inside X-10?

[Charles Sullivan]

You can see what's downloaded to the CM15A EEPROM easily enough.   After you've downloaded, look at file:
  C:\Documents and Settings\All Users\Application Data\Active Home Professional\ahpeeprom_w.txt

It's even annotated for your perusal.

[ArtClark]

Thank-you Charles.  This is EXACTLY the information I was looing for.  I should be able to decode the exact operational
methods from the annotations and the true binary code seems to be there as well (Havn't verified that yet, but it looks like)

My next question though.  Is there any way to actually send the hex/binary directly to the CM15.  Knowing what to change
and how to change it is fine, but if I cannot send this to the CM15, it won't help to be able to change the binary.

I'm sure there is a simple method, but I can't seem to find it in the Documentation for VB, script, or any of the other
places I have looked.  Obviously, I can miss the easy things, seeing I missed this file  ,but maybe someone else isn't
as blind as me?

TIA  (Thanks in Advance....)

[Charles Sullivan]

Thank-you Charles.  This is EXACTLY the information I was looing for.  I should be able to decode the exact operational methods from the annotations and the true binary code seems to be there as well (Havn't verified that yet, but it looks like)

My next question though.  Is there any way to actually send the hex/binary directly to the CM15.  Knowing what to change and how to change it is fine, but if I cannot send this to the CM15, it won't help to be able to change the binary.

I'm sure there is a simple method, but I can't seem to find it in the Documentation for VB, script, or any of the other places I have looked.  Obviously, I can miss the easy things, seeing I missed this file  ,but maybe someone else isn't as blind as me?

TIA  (Thanks in Advance....)

How to Patch the CM15A EEPROM Memory

It's completely undocumented, not well tested, slow going, and you're on your own if you do it.  But you download to the CM15A the same way you would download to the old CM11A, i.e., you send 19-byte packets, each consisting of a 1-byte header (0xFB), a 2-byte Hi|Lo hex EEPROM address, and a 16-byte block of EEPROM code.  The 16-byte block has to be aligned with a 16-byte EEPROM page boundary, i.e., 0x0000, 0x0010, 0x0020, etc.  You can use the 'ahcmd sendrawplc' command in the ActiveHome Pro Software Development Kit to accomplish this from the command prompt.

Steps:

• 1.) Download to the CM15A the original program which is to be patched.
  
  
• 2.) Look up the resulting ahpeeprom_w.txt and ahpeeprom_w.bin files in folder: C:\Documents and Settings\All Users\Application Data\Active Home Professional\
  
  
• 3.) Make whatever changes you want to the binary image file (and remember where you made them).
  
  
• 4.) For each 16-byte page which includes a change, download the entire page as described above.
  

Example:

Suppose you change the value of the byte at EEPROM location 0x0123.  Then you would download the 16 bytes beginning at address 0x0120 including your change:

ahcmd sendrawplc FB 01 20 X0 X1 X2 CC X4 X5 X6 X7 X8 X9 XA XB XC XD XE XF

where CC is your changed hex byte and the XN's represent the other bytes in that page.

Notes:

• Each byte has to be entered as two hex digits (with leading zero if necessary).
  
  
• Wait a few seconds between sending each page -  ahcmd returns before it's actually ready to accept the next command..
  
  
• Someone could probably write a BASIC program for doing this.  If any major changes are made, the initial jump to the start of the timers needs to be nulled out until everything else is downloaded, else all hell will break loose.
  

Have fun!


[TTA Edit: Formatted for improved readability and added to User-Submitted Work-Arounds [Updated: 2007/06/15].]

[ArtClark]

Thanks again.  Now that I know what and where I can start really playing with internal programming.

Of course, this will mean that AHP may not be useable once a Macro is written this way, but it will
always be the starting point.

I've been looking for this and it's like finding the pot of gold at the end of the rainbow.  Now if I can
only learn to utilize it to it's full potential......

Thanks again.