Unravelled

I will start by stating that I encountered the following problem with Toolkit version 1.3. New installtion had approx 40 x 5751L and 20 x 5031NL with 4 or 7 relay modules. Had built the Database using the serial numbers and the sent the product to site to be installed. When I arrived and proceeded to scan the network, there was obviously conflicts so I agreed to the unravel. Some time later I had some units that had aligned themselves with those in the database, while some of the sensors thought they would become a relay. ie Sensors that were unravelled from the network took on the address of a relay even though the serial numnbers did not match. There was a sensor in the DB that it should have associated with but did not. Then we you try and select match serials, it says no need to all serials are matching.
It just doesn't seem to be 100%. Now if v1.4 fixes known issues then great, if not is there a step by step method that will ensure unravel success.

Thankyou

 

CIS are aware of this problem and they working on a fix, but the more (detailed) information you can supply them the quicker it will get resolved.

 

Thanks Colin, exact details of problem are difficult to capture while on-site and it all happens in one unravel. Would be very easy for the guys to replicate I'm sure. But as long as they are on to it I'm happy with that.

Thanks

 

Hi Brett

To tell you the truth, I've never needed to UnRavel a network. The reason being that I ALWAYS program ALL the devices with at least "TagName" and "Network Address" prior to sending them to site.

To do that, I just install them one at a time onto a small network in the office. For each unit I do a "Scan New", then hit "ReAddress", then open the device and "Name" it, then Add To Database. Then I label each with it's name (in a PROMINANT position, not like where the serial number stickers are placed by CIS = useless), put it back in it's box and scan the next one.

So instead of building the database using serial numbers from the boxes, I've always built the database "physically" by wiring each unit on the bench. The big advantage for me is that I can spend minimal time on-site, as the basic stuff is already been done at my desk at my leisure.

I usually also fully pre-program all the Input Units on the desk as well, as you usually always know what has to be done with those. In the process of doing the Input Units, I've automatically created all the GroupNames. Doing all that off-site as well means that the final "programming" on-site only takes about an hour, because all you are doing is opening each Output Unit and assigning the channels with GAs in accordance with how the electricians have physically wired them.

Sounds a bit of a waste of time ? Well it takes about 3 hours to do a decent-sized house worth of equipment, but I can tell you that I have never ever had a problem on-site with any installation (we've always used outside contractors for the physical C-Bus install). You gotta do this naming and addressing stuff anyway, so I just choose to spend that 3hrs OFF-site. The other advantage is that I get to assign things how I want, and it ALWAYS works first go

Yep - I know what I say above doesn't solve your current problem, but it's worthwhile considering as a new way of streamlining your installs in future.

Cheers, John

 

A new way of streamlining your installs in the future???

I would have thought that if the software worked (a special hello to Duncan) the way it was designed / meant to; it would in fact eliminate the need to perform the arduous task of removing each product from the box, connecting it to a temporary network and wasting 3 hours of our time.

Surely you can't serious when you call this process "streamlining"?

 

LOL - well, I call it streamlining because I can't work out any better way of doing it...
- That's not to say that the situation is how it SHOULD be

But seriously, I would never consider trying to commission any project just by scanning bar codes then unravelling and programming it on-site. I simply don't have the time to do all the programming on-site. I prefer to do as much as I can beforehand at the office, as on-site time is horrible time in my opinion.

My main reason for doing that is that I am too lazy to take a chair, table, drinks and a long Com cable. Therefore, I always seem to have to sit on a milk crate with the laptop on a paint tin, in a tiny space under a set of stairs, with no lighting or air. I get dirty, hot, annoyed and my bottom hurts. So it's basically just an OH&S issue for me

OK... I definitely accept that maybe my method is wrong, but I've never actually seen any posts here about how others do "the process".
- So, how do you guys do it ?

 

JohnC
I do the same thing as you, the unravel is to error prone,
It should let you chose the new address for the unit to be unravel not select an addreess it thinks is not used (it only checks spare address from scan and doent look at database).

dave

 

First of all I hear were you are coming from John, secondly before Toolkit Unravel was introduced we used to do exactly what you are suggesting; physically programming the units before they go to site. Yes it does make for a smoother install when on-site, however the initial programming time was a major draw back. Then CIS released Toolkit with serial number matching, perfect just what we need, like a lot of things - sounds good in theory.

The serial number matching works to a certain degree but there are still a number of bugs still to be ironed out. Maybe it's ok on smaller installs, but when you have 90 odd devices on a single network and only half match correctly (this only happens on Friday afternoons) you then wish you had spent the time programming it on the bench before you hit the site.

I have no doubt the preferred method of programming will be via the database and "match serials" on-site, but until these issues are completely resolved I would NOT rely on it.

 

programming

i am with you john
since c-bus was released i have been doing the same as you
iam at home in a nice cumffy chair(not on a cold conrete floor)
i dont care what others think
i look after me and i am happy to do it at home then make small adjustments on site

cheers

 

I've had one of our talented programmers working on this today, its looking much healthier

 

Crouching Units, Hidden Problems.

I'll provide a bit of technical info here, for your interest and to show you that there's no magical panacea for smart unravelling.. yet.

When we have more than one unit at an address on the Bus we can fire a readdress command at that address.. we cannot target a specific unit at the problematic address.. only ONE unit will actually move due to some smarts in the C-Bus protocol..

So we have to move a single unit to a new location then re-query that location to find out which unit actually moved. Then we have to fire another re-address at the same location just in case there was more than two units there. We have to keep firing commands at the address until we're sure no more units are hiding behind others.

New units are being made that are capable of being readdressed based on their serial number, when the penetration of these units is high enough we can move to a much smarter unravelling process which in one step results in the unravel process also doing the "match serials" process. Attempting to use this "readdress based on serial number" functionality in the firmware before the penetration of these types of units is sufficiently high would really slow things down.

In the interim we could certainly follow up the unravel process with an automatic match-serials process (once its working 100%) and that will save you 1-2 mouse clicks.. But in the short term dont expect to see a smart, fast unravelling process. The process is going to have to remain a two step process for a bit longer.. unravel, then match to database.. either by you clicking the buttons, or toolkit offering to do the second step after an unravel (if it detects serial number matchings are possible).

 

Duncan
Idea
Assuming you have a database configured off site and the network is going to have 255 as the address for all new units.

When you do the stage 1 of unravel assign address from 250 downwards, as most database address will be from 1 upwards.
this also stop unravel assigning an address already used in database for different unit.

Then on pass 2 match serial numbers with database and take the unit address from database and readdress units to match.

Two clicks of mouse I can live with and I would think the code used here can be used with the new units.

dave

 

Hi Dave,

This idea came up recently somewhere else.. it seems a common discontent that unravel goes from 1 upwards and not 254 downwards.. when we get a chance, we'll definitely make that tweak. Following that up with the match-serials process automatically (or on a confirmation dialog) would then get us pretty close to where we need to be..

Thanks for taking the time..

 

Nice mod to the Bedford

 

The J1 is looking awesome.. signwriting to be done.. then I'll post some photos