I have a Comfort system with a Dynalite interface. It has been connected for a while and was working just fine. But now it is not? The only thing I can see that has changed is the version of comfigurator. Since a recent download it has stopped working. I am now using V2.1.0
When I send a liner preset from Comfort, this is the response that Dynalite is receiving.
09 Oct 2006 at 15:31:52.091 03 -- -- -- -- -- -- -- <-- 1 Bad Bytes. Timed out after 0ms
09 Oct 2006 at 15:31:52.094 ff 00 65 00 00 ff 56 -- <-- 7 Bad Bytes. Timed out after 0ms
09 Oct 2006 at 15:31:52.116 0d -- -- -- -- -- -- -- <-- 1 Bad Bytes. Timed out after 21ms
Any Ideas, do you think it could be a new bug in Comfigurator. (some values seem to be out by 1) Ie area.
Is there any chance that the number of UCMs have been screwed in Configuration/Modules & Settings or Names/UCMs?
I ask because it looks as though you are not getting valid Dynalite messages. When properly constructed they should always be 8 bytes long.
In my configuration I actually have a UCM01 connected to a DNG232 as opposed to a dedicated Dynalite UCM. In Names/UCM I say that my UCM01 is a Dynalite module and then I get access to the Dynalite messages in the responses window. That way I can have 2-way comms if needed.
are you saying that the DNG232 can accept Dynalite 8 bytes responses into its serial port, and also send ascii strings out the same port by using the task engine in the DNG232. I was hopeing that this was possible but was informed by Dynalite that it was not. Hense I though the DNG232 had two modes,( Configured by software). One allowed the high level ASCII commands, the other the 8 Byte dynalite commands, but not both at the some time.
If what you say is possible, then useing th DNG232, will allow us to use the Comfigurator Response Wizard interface to Dynalyte to generate Dynalite commands, and allow allow the DNG232 to send ascii commands back to Comfort to run responses when the DNG232 detects a specific bit pattern on the dynalite side of the inteface. If this is possible can you please send me some screen shots of how you have configured the DNG232.
The first reason for going with the DNG was that Dynalite over here were not happy having a non isolated device (UCM) connected to the Network. So the DNG provides that via opto isolation.
The limitations you mention may be there. In our application we have not implemented 2 way comms yet. But certainly Comfort is sending the DyNet commands direct to the network through the DNG.
In principle I do not see why it wouldn\'t work as all you are doing is using the task engine to send the text out and starting the task by detecting DyNet events which is all very normal. The task will first need to logon on to comfort and then send it\'s data such as lamp status or lux levels etc. I think the documentation is on here for that.
Perhaps Scott can do some testing on the bench? If I get some spare time when I\'m next onsite with that client I\'ll take a look.
what you say does make sense, and I agree about the benefit of the isolation. If DNG323 can read dynet commands, then that task engine should be able to send out what ever it likes, hopefully. I have a dynalite DNG232 here as well and can test it.
If this works, then we have a good two way solution.
I have moved this topic from Comfigurator to Lighting Interfaces where Dynalite issues are discussed. This will make it easier for other who search our content in future
A redirect wil be left in the other forum so if you are follwing an old link you will find the topic
I guess the question is more on the settings for the DNG232\'s operations. If the DNG232 is set to the DyNet mode, it will definitely accept the Dynalite 8 bytes commands. With a previous conversation with Ian, who did check it out with Dynalite, the DNG232 may not be able to send commands out via RS232 to Comfort in this case, i.e. the DNG232 only supports commands being sent from Comfort to Dynalite in this case.
On the other hand, if the DNG232 is changed to another mode which is bidirectional, the DNG232 does not accept the Dynalite 8 bytes commands, rather it accepts a series of text strings to be used as the command strings, i.e. the commands generated by Comfigurator (Dynalite 8 bytes commands) will not be recognised.
Is there another setting to be changed that would cater for both, i.e. sending out Dynalite 8 byte commands to the DNG232 and being able to send serial commands out via the DNG232?
Just to add on, the application note was written based on the assumption that the ascii text string had to be sent to Dynalite to the DNG232 instead of the 8 byte commands.
I tested the UCM/485 controlling Dyalite from a file generated with Comfigurator 2.1.0. No Problem, works as it is expected. I have also worked out why the DLIGHT2 was telling you that you have a bad byte.
The problem is generated when Jumper G on SW8 ( RS485 AUX) is not shorted. When this jumper is NOT shorted the automatic start of text character (03 Hex) and end of text character (Carriage return OD Hex) that is generated by the UCM is NOT disabled. Thus the UCM wraps the Dynalite command with 03 and 0D characters. The dynalite dimmer handled this OK as the lights did exactly what they were supposed to do. The reacted in exactly the same way independent of wether the Preset command came from the Dynalite switch or the Comfort UCM/485 Dynalite interface.
If looks like the DLIGHT2 software cannot handle these extra characters.
If I short jumper G on SW8 all looks OK on the DLIGHT2 monitor.
The following is an extract of the DLIGHT2 log file, showing the log with and without the jumper in place.
This explains what you are seeing in the DLIGHT2 monitor screen. It does not explain why your commands are not working as my commands worked fine, even thought the DLIGHT2 software monitor could not read the commands being sent.
I think the UCM/485 Dynalite interface manual should be updated to give instructions to short jumper G on SW8 so that the diagnostic capability of the DLIGHT2 software will work.
Hope this helps.
Regards Ian Clarke
Commenced Log Friday October 20 2006 at 10:50.05PM
Time now 22:50:05.242
Generated From Dynalite Switch
22:50:13.213 1c 02 01 00 00 00 ff e2 Area 2 Preset 1 (P1,B1) Fade= 0.02s
22:50:13.836 1c 02 01 01 00 00 ff e1 Area 2 Preset 2 (P2,B1) Fade= 0.02s
22:50:14.482 1c 02 01 02 00 00 ff e0 Area 2 Preset 3 (P3,B1) Fade= 0.02s
22:50:15.326 1c 02 01 03 00 00 ff df Area 2 Preset 4 (P4,B1) Fade= 0.02s
Generated From UCM/485 interface - \"With SW8 Jumper G Open
22:51:21.902 03 -- -- -- -- -- -- -- <-- 1 Bad Bytes. Timed out after 0ms
22:51:21.908 ff 00 65 00 00 ff 7e -- <-- 7 Bad Bytes. Timed out after 0ms
22:51:21.930 0d -- -- -- -- -- -- -- <-- 1 Bad Bytes. Timed out after 21ms
22:51:23.662 03 -- -- -- -- -- -- -- <-- 1 Bad Bytes. Timed out after 0ms
22:51:23.668 ff 01 65 00 00 ff 7d -- <-- 7 Bad Bytes. Timed out after 0ms
22:51:23.689 0d -- -- -- -- -- -- -- <-- 1 Bad Bytes. Timed out after 21ms
22:51:25.310 03 -- -- -- -- -- -- -- <-- 1 Bad Bytes. Timed out after 0ms
22:51:25.317 ff 02 65 00 00 ff 7c -- <-- 7 Bad Bytes. Timed out after 0ms
22:51:25.339 0d -- -- -- -- -- -- -- <-- 1 Bad Bytes. Timed out after 21ms
22:51:26.816 03 -- -- -- -- -- -- -- <-- 1 Bad Bytes. Timed out after 0ms
Generated From UCM/485 interface - \"With SW8 Jumper G Shorted\"
22:53:04.463 1c 02 00 65 00 00 ff 7e Area 2 Preset 1 Fade= 0.00s
22:53:06.287 1c 02 01 65 00 00 ff 7d Area 2 Preset 2 Fade= 0.00s
22:53:07.992 1c 02 02 65 00 00 ff 7c Area 2 Preset 3 Fade= 0.00s
22:53:10.146 1c 02 03 65 00 00 ff 7b Area 2 Preset 4 Fade= 0.00s
22:53:12.411 1c 68 00 65 00 00 ff 18 Area 104 Preset 1 Fade= 0.00s
22:54:23.939 1c 02 00 65 00 00 ff 7e Area 2 Preset 1 Fade= 0.00s
