1.4 Firmware recognition

I've had two problems of late.

1. This is with new C-bus equipment that has arrived in the past weeks. I've created a new project added devices to the database from the database list & scan the serial numbers as I go. The devices then sent to site for installation. The database is preprogrammed. On site the project is unravelled & serial matched with only small problems. Once on network & then open device on database it comes up with firmware matching error you then answer Yes & things get sorted out. This should not have to done as the devices where entered from the database list & is very time consuming when you have to do this to every device especially when 60 odd devices. It appears that the database list provded is out of date.

2. On an existing site which I hav'nt database for when scanned & saved to database the PCI didn't. The date of manufacture 02. I try to open the GUI
but comes up with error. The PCI appears to function as normal in every other way. It looks as when toolkit looks at the PCI for the correct GUI it hasn't got it. I also have one of the same time on my test panel & it appears to have the results.

 

PCI Version

Ashleigh

The PCI at home is version 4.0.0 The other is on site & will check tomorrow.

David

 

We take our best guess at the firmware versions Customers are mostly likely to encounter when commissioning new sites.. taking into account lag through the factory,warehouses and suppliers etc.

Your feedback would appear to indicate we're getting this wrong. I'll take this account in the next release of toolkit and be little more aggressive with the anticipated firmware releases.

Thanks for taking the time to post.

 

I think I asked this before... If Toolkit can interrogate what Firmware is inside a unit, and then list it in the Units Table - it's a bit hard for us poor Users to understand why does it "take our best guess at the firmware versions"

Ok, maybe I've got this all wrong... But if I understand the problem correctly, the Serial is not including any data on what the firmware is. So, using the serial is not an accurate way of inputting the units, as it only contains the product code and a unique identifier - and that unique is NOT accurately matched to the actual firmware in the box.

What is wrong with this approach is that it doesn't takle into consideration that a LOT of us keep stock of C-Bus. Therefore, the unit that goes onto the job will usually come from stock and be quite older than the "best guess of firmware version of current production". So, if the "best guess" is not based on the serial, then it is going to be quite likely to get it wrong !

If you can't actually handle firmware version INSIDE the serial - here's an idea for a "work-around". You could write a tag in the project's *.XML database that the firmware version for the unit was "only a guess" at this stage. Therefore, when the units were physically scanned and the true firmware determined, the "update=yes" could be automatically applied.

That way, firmware is a guess while at Pre-program stage, and then when the job is scanned the true firmware is automatically updated in the database.

If I'm on the wrong track, be kind to me

Cheers, John

PS: This reminds me of another thread where we're discussing the advantages of pre-programming (prior to sending to site) by PHYSICALLY connecting to every unit, rather than pure database programming then relying on serial and/or unravel once installed on-site.

 

JohnC,

99% of the time the mismatch of firmware is pretty much meaningless to users.. we should probably just silently make the adjustment between DB and Network rather than being so upfront about it.

In 1% (and probably less) the firmware change introduces new functionality.. these are the most challenging units.. if you added a (for example) DLT to your database and relied upon the unit having Multiple Application support then when you finally scanned the real unit on the site found that it had older firmware that didnt support Multiple Applications.. well the mess you'd have to sort out is nasty..

 

Duncan

To add to my more information to my previous post. After starting a project on site & you open up a device on the network instead of the database, you make changes on the network & when you save the changes fails to save the database. You then open the device on database to upgrade but be careful not to save back to network or you will lose your changes. Then you have to reopen network device & resave. I long way round. When you open network device & save can't this process then upgrade the database device with the matching serial number. Just a though

Regards
David

 

David,

Thanks for that extra info.. thats a cruddy situation and I'm going to get that nailed before our next release if possible.