ALC Extended Dimming problems

[JayH]

After reading the mixture of conjecture and solid facts from some that obviously have spent time at the protocol level, I finally found time to pull out my test bench from development work years ago and just walk through the test cases (again) to make sure there was nothing I missed before commenting.

Devices
- #1 Dimmer, v1.7
- #2 Relay, v1.6
- #3 Program Switch, v1.1
- No I/O connected
- No Scene switches (lost both of them in the lightning strike, changed to UPB)

Control interfaces
- BranchTech 232/ALC bridge for direct testing of lines
- SLI v1.01 (label fell off & it doesn't id itself, so versions is not 100% positive)
- LMM 1.00 (Serial bridge)
- HLC 1.23
- HLC 1.31

(Why 2 HLC's? Actually, I have 4 - 2 with dead baseboards, through swapping of the 3 not-in-use I found 1 good baseboard & 1 good processor. They really dislike any significant surges or lightning!)

Software
- BranchTech v1.1 (Standalone for raw protocol)
- SceneTech v 2.77

Other
- Interface adapters for SLI/HLC are different than the 232/ALC bridge
- USB to Serial

Leaving out all the messaging details:

232/ALC Direct interface & BranchTech
- Ext Ramp Read/Write work as expected
- Ext Ramp to level works as expected (no controller required for "time base" etc) - it's all handled via a PLL in the device
- Stop Ramp works as expected

SLI v1.01 and SceneTech
- All work as expected

HLC v1.23 via LMM and SceneTech
- All work as expected

HLC v1.31 via LMM and SceneTech
- All work as expected

I realize there are some differences in that I don't have a hub in the picture (yours is passive) and I am using an LMM to get back to 232 instead of the simple 232 interface, but that should not have any impact. If anything, mine should be the more problematic one using the LMM. I also don't have nearly as much wire involved as you do - see my comment below.

Something things to check

(1) Looking at your picture, it looks like you have 7 wires heading out (nice color choice, I did all my ALC in yellow) - what is your distance on these wires and have you tried disconnecting any of them?

I ask because ALC is a "modified" version of RS-485 with a differential signal but a much higher drive voltage and clamping to overcome the reflections that would normally be created by not using terminating resistors on a transmission circuit like this. There is a chance you may be receiving some interference from one of the runs or picking up reflections. (just a thought)

(2) You have _all_ the pairs punched down on each run, not just the communication pair. Are they actually connected at the other end to the remote wires or left dangling?

I never connect them unless I am using them because they will become an antenna to radiate RF noise or pick it up and carry it into the devices - especially if not actually terminated to devices. I can't tell if you have any slaves connected or the wires are just "present" and punched or connected at the device _and_ punched but not used (the last is the worst case).

Let me know if I can run any specific tests on my gear.

Jay

 

[beelzerob]

Man, thanks for the help!

I believe you that the LMM isn't an issue, as JimmyJam doesn't have one of those, and his extended works fine too.

Something things to check

(1) Looking at your picture, it looks like you have 7 wires heading out (nice color choice, I did all my ALC in yellow) - what is your distance on these wires and have you tried disconnecting any of them?

I ask because ALC is a "modified" version of RS-485 with a differential signal but a much higher drive voltage and clamping to overcome the reflections that would normally be created by not using terminating resistors on a transmission circuit like this. There is a chance you may be receiving some interference from one of the runs or picking up reflections. (just a thought)

Hehe...ya, yellow was the obvious choice for lighting. It sure did help when it came time to organize!

I don't know offhand what the distances are on the lengths. I did know there was a length limit, but I figured if it was too long then it'd be more obvious there was a problem. I *can* remove some pairs, but will I end up damaging the distribution module if I pull them out? I'd like to avoid that if possible.... I could also just cut the wires and then slice them bath together, but I'd rather not.

(2) You have _all_ the pairs punched down on each run, not just the communication pair. Are they actually connected at the other end to the remote wires or left dangling?

I'll look again, but I'm *pretty* sure that all of the wires punched down are connected to something on the other end.

I definitely appreciate the help and all the effort you went to, and I'll certainly try anything to narrow this down. But if it *were* one of those two things, I don't understand how just those commands are giving me problems. The set-extended-ramp-rate command doesn't work inconsistently...it just doesn't work period! For any of my dimmers. And all of the other commands appear to work 100% of the time. If it were an interference issue, I'd think that it would have shown up occasionally in other instances.

The only difference I can see offhand between the extended rate write command and all other commands (including the 2 other extended rate commands, which both work) is that it's a 6-byte extended RS232 command...one of the few. I think Ill try to use one of the other ext6 commands and see if they consistently fail too.

 

[beelzerob]

Well, I can confirm that the Clear Reset (write) command doesn't work for any of the devices, dimmers or relays. And that was the only other 6-byte command I could try. But it appears to back-up the idea that for some reason, the ext6 packet type commands are the issue. Or at least a clear symptom.

 

[JayH]

Well, I can confirm that the Clear Reset (write) command doesn't work for any of the devices, dimmers or relays. And that was the only other 6-byte command I could try. But it appears to back-up the idea that for some reason, the ext6 packet type commands are the issue. Or at least a clear symptom.

Yellow = Light. Of course it's obvious! (Blue = Network/Telecom, Green=Other comm links, A-Bus, etc)

Yes, you can pull the wires off (pull straight up, in pairs) without a problem. Use a 110 punch tool to put them back. You can punch them back down in the same place on the wire once, maybe twice, but after that you need to cut it off and make the wire a little shorter. The nature of the compression will start to "clip" the wire after a few times and a break there will be hard to find.

BEFORE you pull all the wiring - just pull the blue/white pair from one of them and wire it direct to pins 4/5 on the HLC Branch 1 RJ45 (no, I don't remember +/- ordering) and see if that single dimmer will work with the commands. If you have an OnQ telecom module (passive) that will also work to connect an RJ45 into and use as a breakout.

If you send me the exact commands in hex and the rate, I'll verify them. Dimmer address 1 preferred!

I agree that I would expect it on other commands, but I've seen stranger. 4 bytes = ~4ms, 6 bytes = ~6ms (@9600 baud, including framing) so it is a fraction longer and _could_ be having a problem with reflections / harmonics. As a part of this, do you have any hard kinks in cables - they could aggravate this issue (if it is the issue) You were looking for ideas ...

I think this was also brought up, but you have verified that it isn't working? The HLC is generating a NAK because it never received an ACK back from the device, doesn't mean the device didn't see it and the ACK just got stepped on.

Jay

 

[TonyStewart]

There sure is a lot of wisdom being shared by you folks. There is little I can add.

As for cable lengths, our test jig has 4 branches with over 100 total ALC switches in use. Branch 4 has over 750' of cat5 used for the communication loop (500' is suggested max for a branch) . We just fired this test jig off a few weeks ago, but have not seen any cabling issues yet. However, our setup does not test cabling ran too close to other potentially harmful electrical noise soures, it just tests losses due to voltage drops.

In your case, you have a very specific issue which does not change. Long or noisy cabling runs most often cause sporadic failures, not specific repetitive ones.

TS

 

[beelzerob]

I agree that I would expect it on other commands, but I've seen stranger. 4 bytes = ~4ms, 6 bytes = ~6ms (@9600 baud, including framing) so it is a fraction longer and _could_ be having a problem with reflections / harmonics. As a part of this, do you have any hard kinks in cables - they could aggravate this issue (if it is the issue) You were looking for ideas ...

I think this was also brought up, but you have verified that it isn't working? The HLC is generating a NAK because it never received an ACK back from the device, doesn't mean the device didn't see it and the ACK just got stepped on.

Jay

No kinks that I *know* of.! I made sure there was none when I laid the cable, but it's always the unknown one's that get you. Besides, since all 5 devices are failing the ext6 command, it would mean an awful lot of kinks out there.... There's no sharp turns anywhere that the wire comes visible to the can (it's all out in the open).

Ya, I checked if it was really getting it by doing an extended rate read again, and it's still set to 5.

I'm testing with the scenetech software, so since you are too, whatever bytes you're getting are what I'm getting too, and also correspond with the protocol doc.

But as a check, these are the bytes Bill gave me in the previous thread to this for setting the ramp rate on address 1 to like 2 hours.

81 35 12 18 00 20

When I use the scenetech software to set my dimmer on address 1, those are the exact same bytes I get....AND the same bytes my cqc driver produces too, all of which get a NAK back.

I know what you're talking about, as far as wiring the comm wires directly to the HLC, that's how I did my very first testing. I wonder if I kept that rj45 somewhere.... But I'll give that a try.

 

[beelzerob]

The plot thicks....

Instead of having to pull wires out of the expansion module, I decided on a simpler course.... I've got several dimmers laying around (waiting for their special day...), so I'll just wire one of these to a light source nearby and then plug its control wires directly into the HLC.

So, some *very* ugly wire connecting later, sure enough, I had a single dimmer connected by about 8" of cat5 directly to the HLC. I started up scenetech, and was able to query the status, set the light level, query the extended dimming rate (set to 5, like the others), but was NOT able to set the extended dimming rate.

I've thus ruled out my dimmers and wiring from being possible causes of this problem. Well, really that only leaves either the HLC itself or the serial expansion module.

On a side note...I did a little testing with the "Set level via extended dimming" command. Since the extended dimming rate was already set to 5 (by default, apparently), I just wanted to see if it actually took 12 seconds to dim, since normal "ramp to level" takes about 4 seconds from full on to full off. Sure enough, it took *about* 12 seconds to extended-dim-to-level from full on to full off. However, I then set the level of the light to 30%, so just barely on. When I then used the extended dim function to set the level to 0, it turned off almost immediately.

All that to say that there's an important cavaet to how the extended dim function works (so far as I can tell). If you set it to 1 hour of extended dim time, what you're really setting is the RATE at which it will dim, not how long it will take to go from the starting level to the ending level. If you were setting the TIME it takes to dim, then going from 30% to OFF would take the same amount of time as 100% to OFF....but it doesn't. So, you're really setting the time it would take to go from 100% to OFF, and that *rate*will be applied no matter what level the light starts at or finishes at. Make sense? And please, those of you helping, feel free to verify that...maybe it's another aspect of how my stuffs not working right. I wouldn't call it a problem at all...just an important understanding of how the extended ramp function works.

 

[JayH]

Instead of having to pull wires out of the expansion module, I decided on a simpler course.... I've got several dimmers laying around (waiting for their special day...), so I'll just wire one of these to a light source nearby and then plug its control wires directly into the HLC.

So, some *very* ugly wire connecting later, sure enough, I had a single dimmer connected by about 8" of cat5 directly to the HLC. I started up scenetech, and was able to query the status, set the light level, query the extended dimming rate (set to 5, like the others), but was NOT able to set the extended dimming rate.

I've thus ruled out my dimmers and wiring from being possible causes of this problem. Well, really that only leaves either the HLC itself or the serial expansion module.

So lets take this as good news for the moment, because now you have a test setup that fails that is independent of all external factors.

A new round of questions:
- What is your serial interface (USB, PCI, ... Brand)? Have you used it with other binary protocols?
- What version of SceneTech (2.77 I believe is the most recent)
- Have you tried another PC or laptop to control them?
- Do you have a serial protocol analyzer to see what is actually being sent to the HLC?
- Is the serial cable/adapter the ones that came with the HLC Serial interface, or custom? Have you tried the originals?

On a side note...I did a little testing with the "Set level via extended dimming" command. Since the extended dimming rate was already set to 5 (by default, apparently), I just wanted to see if it actually took 12 seconds to dim, since normal "ramp to level" takes about 4 seconds from full on to full off. Sure enough, it took *about* 12 seconds to extended-dim-to-level from full on to full off. However, I then set the level of the light to 30%, so just barely on. When I then used the extended dim function to set the level to 0, it turned off almost immediately.

All that to say that there's an important cavaet to how the extended dim function works (so far as I can tell). If you set it to 1 hour of extended dim time, what you're really setting is the RATE at which it will dim, not how long it will take to go from the starting level to the ending level. If you were setting the TIME it takes to dim, then going from 30% to OFF would take the same amount of time as 100% to OFF....but it doesn't. So, you're really setting the time it would take to go from 100% to OFF, and that *rate*will be applied no matter what level the light starts at or finishes at. Make sense? And please, those of you helping, feel free to verify that...maybe it's another aspect of how my stuffs not working right. I wouldn't call it a problem at all...just an important understanding of how the extended ramp function works.

I did a quick test and saw the same effect - vague recollection of reading about this in some documentation - because there is a formula I looked at long ago for doing this. Verify the math (remembering the level is 0..127, not 0..100):

Ramp Rate = (ramp duration in seconds / 2.33) * (127 / abs(current level - desired level))


Happy Hunting,

Jay

 

[beelzerob]

A new round of questions:
- What is your serial interface (USB, PCI, ... Brand)? Have you used it with other binary protocols?

RS232 via PCI add-in card. I've also tried it with the native RS232 port on the motherboard. I've used both of these with numerous other devices and notice no problems, whether ASCII or binary protocols.

- What version of SceneTech (2.77 I believe is the most recent)

2.50

- Have you tried another PC or laptop to control them?

Well, it's kind of always been attached to the CQC machine, but that itself has gone through a motherboard transformation, so I'd say ya.

- Do you have a serial protocol analyzer to see what is actually being sent to the HLC?

Nope. It'd be handy to know if the HLC was rejecting the message being sent to it by the serial adapter, or it was rejecting it because the dimmer didn't respond....

- Is the serial cable/adapter the ones that came with the HLC Serial interface, or custom? Have you tried the originals?

I made the cable based on the PDF doc I got. I'm not sure I have the originals...or I guess I do. Its a very VERY short piece of red cat5, right? I'm not sure how I'd hook that up to anything, the cable is so short.

I realize we do need to try everything...absolutely we do...but it'd be pretty strange to think a bad or miswired cable only affects those commands, and consistently (while consistently letting the shorter commands get through).

 

[beelzerob]

I'm beginning to wonder if I've got a quirky/flakey serial comm unit or something. The reason I wonder is because of all my devices, the ALC unit has been the most unstable when I've tried connecting to it through my Quatech serial port server. I've tried using the quatech virtual comm port drivers, VERY unstable. I've tried the Lantronix serial port redirector...unstable. I've tried HW-VSP...unstable. I've now also tried talking directly over TCP/IP to the quatech box (which then talks to the ALC comm panel), and that is ALSO unstable.

By "unstable", what I mean is that I'll send a request for a light level to a dimmer, and I'll get back a NAK. At other times, it will respond normally. Or I'll send a request for a device status, and I'll get back the 0x40 byte, meaning "a message is coming"...and then nothing comes next.

These problems all seem to go away when I connect directly to the comm ports on the PC...but really, the other methods *should* work. They work for many other devices I have hooked up in the same manner. I think the ALC is either flaky, or just quirky, or just too picky. MAYBE that is a symptom of the problems I'm having with the extended ramp rate setting.


Anyway, let me remove the comm connection cable from possibility. I have 2 short, red cat5 cables that come with all the equipment. One of them is in the pic above, connecting the distribution panel to the HLC. I think the 2nd one I have is wired the same. Is either of these things what is supposed to come with the comm panel for connecting to a PC? If so...they're obviously too short! So, can someone give me the definitive mapping of DB9 pins to RJ45 pins for making my own cable? I know it's in a doc (that's how I made the one I have now), but I'd rather hear it directly from someone who has one working. I'll check what I have to this "standard". Maybe I didn't hook up all the pins. *shrug*.

 

[beelzerob]

Well, I'm down to these 3 things left that it possibly could be:

1) The cable from the PC to the serial expansion module.
2) The serial expansion module.
3) The HLC module.

If someone can give me the pinout of a working cable, I can remove that from the list. Then I'm at a dead end!

 

[JayH]

Well, I'm down to these 3 things left that it possibly could be:

1) The cable from the PC to the serial expansion module.
2) The serial expansion module.
3) The HLC module.

If someone can give me the pinout of a working cable, I can remove that from the list. Then I'm at a dead end!

The cable. Remember the RJ45 is numbered 1-8, left to right, with the notch towards you.

DB9		 RJ45
RX  2 ---- 4  TX
TX  3 ---- 5  RX
GND 5 ---- 2  GND
RTS 7 ---- 3  HLC/LMM Select

Note that the RTS is only needed if you also have an LMM.

Based on comments above regarding instability only with ALC, verify you have a solid ground connected on your cable (DB9-5/RJ45-2) because that may create some of the issues.

Also, it appears you are running with the original transformer but it was never explicitly asked. Be aware that the power ground is tied to the serial ground, if you have a 12VDC distribution system with a number of devices tied back to your PC then you need to be aware of the potential for ground loops. Even more so if you have an Elk involved and serial-attached RS232 devices on common power.

Jay

 

[beelzerob]

Thanks for the reply and helpful suggestions, Jay!

1) I just checked the db9-rj45 adapter I have been using, and it fully conforms to the list you put, even the HLC/LMM select pin. Basically, I wired the adapter as indicated, I plug the adapter into the PC, and then I just normal network-wired cat5 to go from the adapter to the HLC. I also checked that no other pins were wired to the RJ45, and they're not. Those 4 are the only pins wired.

2) The ground is solid, so far as the continuity tester I was using indicates.

3) Yes, original transformer. Nothing else is being powered by it.

So then...that means we're down to the ALC hardware itself, right? Or am I missing some other possibility?

 

[wlj]

So then...that means we're down to the ALC hardware itself, right?

Rob,

I wanted to reiterate that I'm having the same difficulties you are using the Quatech with my ALC SLI. I've been left with the impression over the years that the ALC serial protocol is extremely timing sensitive. The only devices I've ever managed to get talking to my ALC SLI with 100% transmission accuracy are native PC serial ports and the Digi/Inside Out EdgePort USB->Serial devices. I've had varying degrees of failure with other USB->Serial and all Ethernet->Serial converters.

Or am I missing some other possibility?

That things are "operating as designed", but not "as desired"? That was, essentially, the conclusion I came to.

Cheers,
-Bill

 

[beelzerob]

Well, I do have a limited number of native PC ports I can decide to allocate for certain devices....sounds like the ALC will be one of them. Thanks for the reminder that I'm not alone, Bill. The edgeport works, though, huh? I knew I shoulda gotten sucked into that ebay deal...

Let me be clear for everyone, though...all of the problems I've been having with the ALC were through a native PC port...so my complaints about it being finicky on other devices isn't related to the extended dimming issue I'm having.