Print

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

[Boiler]

Boiler,

NOP (assembly language - no operation)

you're showing your age......pretty soon we can talk about autocoder and hardwiring logic boards.
I guess you can recognize the following
12
11
0
1
2
3
4
5
6
7
8
9
and you might even know who Grace Murray Hopper is and that the above is a 5081.
 

spam4us,
I gave up trying to hide my age some time ago (the term Grey Beard is quite literal here).

Thanks for the 5081 hint in your post.  It's been a few years (maybe 25) since I've used cards.  I doubt we have any readers left at work.  We do have a Vax and an 11/70 which are used on some automated test stands.

Grace Murray Hopper - yep, I once programmed in COBOL (only once).  I may still have some of her guidlines in a file cabinet somewhere.

Actually had the opportunity to "revise" the assembly code on a test stand early this year.  We still have a number of dedicated stands that are based off the old TI 9900 processor.  This particular stand had a massive amount of ram (16K) spread over 4 expansion boards.  It was actually quite a lot of fun - really took me back. 

Nice to meet another "Oldtimer"

[-Bill- (of wgjohns.com)]

I have (I haven't fixed it yet) an interesting and related problem with flags.

My keychain remote is set to house code B.

I created a MACRO to trigger on B1 On (and another similar one for B1 Off).

The first draft B1 On macro simply sent L1 On to turn on a living room lamp.

This way I can re-assign the keychain button by simply changing the B1 On MACRO in AHP instead of actually changing the settings of the keychain remote or modules!   

After playing with AHP, looking at the Activity Monitor, and playing with programs written with the SDK, I discovered the fact that most remotes send multiple signals if the button is held down for any period of time.

So, I decided to get tricky and prevent the MACRO from being re-triggered if the MACRO was already executing, by using a SmartMACRO's flag.

The modified MACRO for B1 On checks to see if flag 1 is Off and only executes if flag 1 is Off.

If flag 1 is Off the MACRO executes, and the first thing it does is set flag 1 to On.

It then sends the L1 On and sets flag 1 to Off.

This works great to prevent the MACRO from re-triggering while it is already executing.

The problem I have been having is that after a power failure the keychain remote would no longer turn on (or off) the light.

I could see the signal in the Activity Monitor and the MACRO flashed in the AHP display as if it was being triggered, but nothing happened with the light!   

More interesting was that if I clicked the MACRO in AHP, it worked!  Not only that, but the keychain remote worked from then on too!

I finally realized that flag 1 in the CM15A wasn't set to Off when the CM15A lost power... as a matter of fact, it appears to be On by default!

Triggering the MACRO manually by clicking on it in AHP ignores the conditions (ignores the fact that flag 1 is not Off) and the MACRO executes.  Since the MACRO turns flag 1 Off at the end, the next press of the keychain button finds flag 1 Off as expected and the MACRO executes as expected.

Moral:  Never assume!  Test, test and re-test!   

[spam4us]

Bill- (of wgjohns.com) ,

     What you can do is create a macro that is triggered with a P16 On that will reset your flags (or at least flag 1 in this case).  AHP sends a P16 on after a power failure.  I'm not sure exactly what makes this happen but the P16 On is always sent according to my activity monitor.
     

[steven r]

...What you can do is create a macro that is triggered with a P16 On that will reset your flags (or at least flag 1 in this case).  AHP sends a P16 on after a power failure....

Unfortunately I've never been able to get that power up P16 ON signal to trigger a macro.

[JMac]

I have a macro that will work with P16.  Designate a "ghost" module as P16, and then have a macro using P16 as the trigger.  The first item on the macro is a 30 second delay (that's how long it takes my computer to autostart AHP) followed by the action you want.  I use a 5 second delay after that to turn off the P16 module.  I can use this to arm OnAlert, for example.

[Puck]

Unfortunately I've never been able to get that power up P16 ON signal to trigger a macro.

Have you tried all variations of: stored in interface, run from PC, house code P transceived, house code P not-transceived?

I have not tried P16 within a single CM15A, but since I have 2 of them running, the P16 signal from one triggers a macro in the other. This has worked quite well for me so far.

[Tuicemen]

It has been noted before that an extra transceiver is needed to make use of the P16 on power up command!

[steven r]

It has been noted before that an extra transceiver is needed to make use of the P16 on power up command!

So is the "P16 ON" command an RF signal rather than a power line signal?

[Tuicemen]

So is the "P16 ON" command an RF signal rather than a power line signal?

The p16 On command is sent RF!One note on flags:
There is/was an issue with flags 1,15 &16 although they appear to be fixed in  ver 3.206 on XP, Old problems have a tendency to pop up again in updates and depending on which OS your using!
Doing an advanced search will turn up lots of discussion on this!
For this reason I still avoid these flags!

[Puck]

There is/was an issue with flags 1,15 &16 although they appear to be fixed in  ver 3.206 on XP, Old problems have a tendency to pop up again in updates and depending on which OS your using!

I have been using 1 & 15 reliably (Ver 3.206 on win2k), but I have seen 16 still get cleared just by the process of running a macro... so 16 is the only one I now avoid for anything meaningful.

I do use #16 when I want to start a macro with a delay. Because of the documented issues, I start the macro with a Clear Flag 16 followed by the delay. This meaningless step has helped me work around the start with a delay issue. 

[Boiler]

I have been using 1 & 15 reliably (Ver 3.206 on win2k), but I have seen 16 still get cleared just by the process of running a macro... so 16 is the only one I now avoid for anything meaningful.

I do use #16 when I want to start a macro with a delay. Because of the documented issues, I start the macro with a Clear Flag 16 followed by the delay. This meaningless step has helped me work around the start with a delay issue. 

Puck,

Nice touch with the otherwise useless flag #16.  That's helpfull.

Like you I have bee using flags 1 and 15 without problems for some time.  I'm running XP and AHP 3.204.

I've also had problems with the "start with a delay issue".  Unfortunately (or maybe fortunately), I just tried reproducing the delay at the beginning of a macro problem and everything works great??  I've used RF, Time, and Powerline triggers to the macro. 

Did something get "fixed" in AHP, or am I not remembering the problem correctly?

Boiler

[Puck]

I've also had problems with the "start with a delay issue".  Unfortunately (or maybe fortunately), I just tried reproducing the delay at the beginning of a macro problem and everything works great??  I've used RF, Time, and Powerline triggers to the macro. 

Did something get "fixed" in AHP, or am I not remembering the problem correctly?

I don't think anything got fixed yet; the problem appears when the macro is part of an Else.