Print

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

[MD Corie]

...
You mentioned that you might not have all devices defined, or not properly. That could certainly be causing problems.
Don't share the save HC/UC between device types (or between SoftStart and non-SoftStart devices). Ever. (The only exception would be a "dummy" appliance module set to the same HC/UC as a macro, and used to call that macro from another macro.)

Any command you are sending from a macro should be linked to a VALID (and properly defined) device in your AHP setup.

Clear your AHP trash can. Macros have been know to still run from the trash in some cases.

...

Do you have any feel for what issues would result from having commands on the PLC for devices that have not been defined in the AHX? (This would be the same situation if I try to use the Log file on a "bare" system, only worse there).

I don't believe there are any situations where multiple physical devices share the same code.  The situations I was referring to are in the nature of defining a simple virtual Appliance Module for a dimmable physical Lamp Module.  This is because I use only On/Off control for those particular lights, and the "correct" virtual modules cause bright/dim commands to be issued for simple on/off functionality, and thus slow down the execution considerably - as well as allowing more "room" for collisions to occur, due to the extended-duration commands.  (All such cases are "output devices" as far as the macros are concerned... that is, they are controlled-only, and do not do any macro triggering).

If macros run from the trash can, then that re-visits my earlier question about which macro actually runs if you have one version in the interface, and another in the PC.  Now, it appears that we must also deal with a third possibility... which begs the question of which one is going to run if a macro having the same trigger code exists in all three places?  Hopefully, there is some definitive answer to that question... although if X10 is not going to say how multiple macros behave, then probably there is little chance of getting this answer, either... and, IMO, withholding those answers are serious problems.

[Noam]

I'm going to try and work backwards through this one.
1) I don't think they are "withholding" the information. They just haven't gotten around to giving it to us yet. As I (and others) have said, the X10 reps aren't reading the boards every day. I've sent e-mails off to one of the developers, but he might be on vacation.

2) There ARE bugs and design flaws in AHP. Nobody is disputing this (we have a long list here: http://forums.x10.com/index.php?topic=22373.0). However, there are things that can be done to minimize their effects (ie: workarounds). Emptying the trash is one of these workarounds.

3) If you are defining a "virtual appliance module" for a physical lamp module, do you also have the lamp module defined in AHP?

4) If you don't have the modules defined in AHP, how are you sending them commands in the macros? Are you using the advanced function to send the discrete codes directly from the macro? The preferred way to do it is to define the modules (properly) in AHP, and use those in the macro sequencing.

5) If the macro operation seems to get MORE messed up with the real motion sensors, then perhaps something isn't set up correctly, or the motion sensors aren't configured right (or aren't working properly).

[MD Corie]

1)  I am not so much inclined to give X10 the benefit of the doubt because they actually have withheld necessary operational and usage information from me in the past, that caused me to waste a lot of time unnecessarily (due to figuring things out - sort of - via trial and error) and even prevented me from solving problems that prevented successful use of some devices.  I have no idea why they keep things so "close to the vest", as it doesn't appear that we were treading close to anything proprietary.

In any case, it makes me wonder if the same situation is occuring with the info for the software... but the real bottom line is that people can't use the stuff properly/effectively if they don't have all of the necessary information... and I feel that not providing it (for whatever reason) is just plain unacceptable.  Imagine if someone like National Instruments were to sell their FieldPoint equipment without providing full information about programming the devices, or not providing the full specs for interfacing their devices to other equipment.  I don't think they'd sell much of the stuff - at least not for very long.

Anyhow...  back at the ranch:
2)  I don't have a problem, per se, with flaws and bugs;  it becomes a problem when there are no steps taken to correct the bugs, or no information provided to achieve temporary patches while problems are being corrected... especially if it means that an entire system is out of service due to the problems.

Regarding emptying the trash, in my case, I typically do not have anything "residing" in the trash, so I'm guessing that is not an issue here - but I will make sure of that in the future.   I will also review the list of problems and work-arounds to see if there is anything applicable there.

3)  In such cases, the virtual module is (of course) defined in AHP but there is no "correct" virtual module also defined in AHP - that is, no duplicate virtual modules exist for any given physical module.

4)  I'm not sure I understand the question here;  possibly there is some misunderstanding of what I have been saying?  There are AHP virtual modules (of some type) defined for each controlled physical module... so I'm not sure that I follow the question here.

Note:  Please be aware that the cases where a surrogate virtual module is used in place of the "correct" virtual module are very limited in scope, to perhaps three "special case" modules at most... it is not a typical or widespread implementation, and certainly does not involve all of the macros by any stretch.

5)  Again, I'll have to raise the question of how to define "set up correctly".  When it comes to the PR511s, the question of "correct" settings often raises its ugly head... as far as getting the anticipated results in actual operation.  (By the way, this is one of the areas where information was withheld, as mentioned earlier).  And, based on past experience, it is entirely possible that one or more of the PR511s is not working properly... but, if that is the case, then it must be connected somehow with macro action - because that is the only time any glitches are seen currently.

Please keep in mind during this discussion that the hardware in this system (and the supporting electrical system) has already been tested exhaustively - to the extent that it can be evaluated without specialized test equipment - and no known hardware or "infrastructure" problems currently exist.  It is quite literally a case where the problems show up only when multiple macros execute at the same time.  I'm not ruling out some sort of hardware problem, but the circumstances seem to indicate that is a very low probability, so I'm inclined to believe that chasing such trails is likely just a waste of time.  At worst, it would be a case where some otherwise undetected hardware problem(s) manages to show up only in association with multiple macros running... so logically, those aspects would be the most likely suspects to investigate.

[Noam]

Okay, I give up. I have no idea why your system won't work right.
Without seeing your AHX files and/or your logs, there isn't much more I can do to help you. Sorry.

[MD Corie]

Okay, I give up. I have no idea why your system won't work right.
Without seeing your AHX files and/or your logs, there isn't much more I can do to help you. Sorry.

No problem... (That makes two or three of us who have thrown up our hands over this).  Just to be clear, though:  The "system" works; the macros don't.  We actually had a limited-functionality hardware-only system working at one time, but needed to overcome some limitations (like not being able to control a VCR) and the AHP system -supposedly- offered ways to handle the limitations, ability to control the VCR, ability to coordinate multiple cameras, added system flexibility, and even ways to add some bells and whistles.  Between its actual inability to coordinate cameras and the macros fiasco, it's looking look like AHP was more mistake than benefit.

I will see what I can do later this week about generating some sample logs that show the garbage that occurs when two or more macros run at once.  I hope someone can make more sense of them than I have been able to.

[Noam]

I will see what I can do later this week about generating some sample logs that show the garbage that occurs when two or more macros run at once.  I hope someone can make more sense of them than I have been able to.

As I've said, I'm more than willing to take a stab at it, but you haven't given us any data to look at.

[MD Corie]

I will see what I can do later this week about generating some sample logs that show the garbage that occurs when two or more macros run at once.  I hope someone can make more sense of them than I have been able to.

As I've said, I'm more than willing to take a stab at it, but you haven't given us any data to look at.

Well, it has taken some time to get to this with everything going on around here, but I now have some sample logs.

Unfortunately, I have not been able to capture any of the really wild (gibberish) stuff where it looked like there were totally "foreign" commands showing up, or partial commands, etc., but the sample log did get fairly confusing - especially towards the end... so, maybe that is at least worth taking a look at, because there might be some clue there.  As time permits, I'll try to capture some of the really wierd stuff, too.


Meanwhile, here's what I did:

First, I ran each of the three typically offending macros via a remote trigger (to get a log of what they should look like when they run without any sort of interference from concurrent macros).  I saved the AHP Activity Log file after each run, and then cleared the Activity Log for the next run.  These "stand-alone" samples all appear to be pretty consistent with their associated macros, both in terms of commands being correct and in the proper order, and delays working more or less as expected.  (Note:  I ran the daytime version of these macros, because the night versions get even more "hairy" with lighting control actions - so I figured the simpler forms would be better for now).

Second, I cleared the Activity Log, and then went out and triggered the actual motion sensors under "typical" conditions of someone walking through the area.  I then came in and waited until all the motion sensors had issued their respective turn-off commands, and then saved the resulting log to a file.

It looks like the "actual run" log initially shows that the first macro is running normally;  then the second sensor triggers, but it looks like all commands in the log are still coming from the first macro.  Then the third sensor triggers and it looks like some commands are getting interspersed occasionally, but essentially it is still the first macro running.  Then things start getting confusing, and I'm not really sure what is running - although I think all the logged commands can be attributed to one of the three macros... but it looks like the delays are not always correct - or maybe not happening at all.  Anyway, it becomes quite confusing, and doesn't seem like things are happening in their proper order, etc.

Over all, my impression is that the subsequently-triggered macros don't really run while the first macro is already (still) running, although at some point, they do seem to start getting muddled together - but that's quite awhile after the subsequent macros get triggered... so there must be more to this than macros simply running concurrently.

So, let me know what you make of it....

(Note:  I had to rename the .htm log files to .txt extensions in order to attach them here).

[Noam]

Thanks for sending the logs.
It will take me a little while to go through them, and compare the "actual" run to the "testing" runs.
One more thing that might help, if you can, would be to post a list of the commands in each macro.
something like this:

Camera C5 On
Delay 5 seconds
VCR On
Indicator light N1 on

etc.

[MD Corie]

Thanks for sending the logs.
It will take me a little while to go through them, and compare the "actual" run to the "testing" runs.
One more thing that might help, if you can, would be to post a list of the commands in each macro.
something like this:

Camera C5 On
Delay 5 seconds
VCR On
Indicator light N1 on

etc.

Yeah, I was going to do that, but I didn't see any easy way to output only that specific info;  is there some "quick and dirty" way to get only that stuff - without having to type it out manually, nor dump the whole works?

[Noam]

Thanks for sending the logs.
It will take me a little while to go through them, and compare the "actual" run to the "testing" runs.
One more thing that might help, if you can, would be to post a list of the commands in each macro.
something like this:

Camera C5 On
Delay 5 seconds
VCR On
Indicator light N1 on

etc.

Yeah, I was going to do that, but I didn't see any easy way to output only that specific info;  is there some "quick and dirty" way to get only that stuff - without having to type it out manually, nor dump the whole works?

Nothing that I know of.
The best way would be to type it out. That would also give you a chance to double-check the macro sequencing, and see if there might be something contributing to the issues you are having.

[Noam]

I started taking a look at your log files.
Without a clear idea of what each macro is *supposed* to do, I'm having a lot of trouble just following a singe macro's execution.

I looked at the "Entry Macro Sensor" log, and I can't tell where there are supposed to be delays, or if there are other macros being triggered from within these or not. It is really hard to follow what this macro is trying to do.

When you get a chance to post the step-by-step execution of what each macro is supposed to be doing, I think that will help me out.

[MD Corie]

I started taking a look at your log files.
Without a clear idea of what each macro is *supposed* to do, I'm having a lot of trouble just following a singe macro's execution.

I looked at the "Entry Macro Sensor" log, and I can't tell where there are supposed to be delays, or if there are other macros being triggered from within these or not. It is really hard to follow what this macro is trying to do.

When you get a chance to post the step-by-step execution of what each macro is supposed to be doing, I think that will help me out.

Here are the basic macros and -hopefully- all of the possibly-associated macros.

[Noam]

Wow.
I took a look at two of the files. That's a really complicated setup you have.
It will take me a while to go through everything, and look at what it is trying to do.
One thing that struck me as odd, however, is in the "Entry Sensor Macros," It looks like you are turning on camera C3, and then turning it right off. What's the point?

If you could provide a short paragraph, explaining what each macro is supposed to do (turns on camera 1, then switches to camera 2, triggers macro that rings a bell, feeds the cat, makes the coffee, and fetches my slippers), that would also be helpful.
I have a feeling you might have just made everything too complicated, and that's why you are running into issues.
You say that each macro works fine on its own, but it looks like you have macros calling other macros, and possibly having those call others. I still haven't gotten an answer about the command buffer, or the order of operations when one macro is called while another is working.
I know that the execution of the first one doesn't stop (it doesn't matter if the second one was called by the first, or by some other independent trigger), but where the new macro's commands fit in isn't all that clear to me.

[MD Corie]

Wow.
I took a look at two of the files. That's a really complicated setup you have.
It will take me a while to go through everything, and look at what it is trying to do.
One thing that struck me as odd, however, is in the "Entry Sensor Macros," It looks like you are turning on camera C3, and then turning it right off. What's the point?

If you could provide a short paragraph, explaining what each macro is supposed to do (turns on camera 1, then switches to camera 2, triggers macro that rings a bell, feeds the cat, makes the coffee, and fetches my slippers), that would also be helpful.
I have a feeling you might have just made everything too complicated, and that's why you are running into issues.
You say that each macro works fine on its own, but it looks like you have macros calling other macros, and possibly having those call others. I still haven't gotten an answer about the command buffer, or the order of operations when one macro is called while another is working.
I know that the execution of the first one doesn't stop (it doesn't matter if the second one was called by the first, or by some other independent trigger), but where the new macro's commands fit in isn't all that clear to me.

I have attached description files for the macros.  I think the description will answer your question about the camera control.  Generally speaking, though, most everything in those macros is done to compensate for or workaround hardware limitations or problems, or idiosyncracies.  It is a pain in the a**, but those "fixes" were a big part of the reason for going with the macros rather than a hardware-only system.  I do, however, feel that the actual purpose of the macro steps is irrelevent to their proper functioning in an absolute sense.  It certainly may be that there is some logic error that might lead to undesired outcomes... but, that in itself should have no bearing on whether the macros execute the steps in the proper sequence, depending on the individual instance.

I have to disagree with both the idea that the macros are "too complicated" and the idea that complexity would lead to the malfunctions seen.  (If this is indeed the case, then one can only presume that the macro software is pretty weak).

When I said that each macro works OK on its own, I was actually referring to the macro and its called sub-macros as a unit... which, of course, implies that each sub-macro also works OK by itself, too.

From the logs I've examined, it appears that the first macro generally retains control until it completes (or until it hits a delay command), at which time, commands from other "pending" macros show up in the log.  After that, it often becomes unclear whether the first macro resumes, or what actually is going on.  If there is some limitation to the "depth" of the calling tree, then it may be possible that these macros are exceeding that depth, and thus fouling up.  However, in such case, it is apparently the multiple motion sensors that are "overloading" the "queue", because the macros do work OK individually - as can be seen in the sample logs.

[Noam]

I have to disagree with both the idea that the macros are "too complicated" and the idea that complexity would lead to the malfunctions seen.  (If this is indeed the case, then one can only presume that the macro software is pretty weak).

Well, it was written 7 years ago, and hasn't really been changed since. It was never designed to do a lot of what people are actually doing with it (like calling one macro from another, for example), so it is perfectly reasonable to me that it has certain limitations, and it is possible to exceed those limitations with a large setup.

When I said that each macro works OK on its own, I was actually referring to the macro and its called sub-macros as a unit... which, of course, implies that each sub-macro also works OK by itself, too.

Well, that's something the system was never designed to do in the first place. Why do you think we need a workaround to call one macro from another in the first place?

From the logs I've examined, it appears that the first macro generally retains control until it completes (or until it hits a delay command), at which time, commands from other "pending" macros show up in the log.  After that, it often becomes unclear whether the first macro resumes, or what actually is going on.  If there is some limitation to the "depth" of the calling tree, then it may be possible that these macros are exceeding that depth, and thus fouling up.  However, in such case, it is apparently the multiple motion sensors that are "overloading" the "queue", because the macros do work OK individually - as can be seen in the sample logs.

Once again, there is a limit to what the CM15A can do. You might have found it.