Sevcon Gen4: Old DCF on a newer DLD

methods

1 GW
Joined
Aug 8, 2008
Messages
5,555
Location
Santa Cruz CA
That's a topic for discussion.

I propose a test

Procure 2pcs DLD file... one older... say 2012.... and one newer... say 2016
Procure 2pcs DCF file... one older... say 2012.... and one newer... say 2016

Load 2012 DLD then 2012 DCF, make minor adjustments, confirm good performance
Load 2016 DLD then 2016 DCF, make minor adjustments, confirm good performance

Baseline set
Known goods all around
DLDs, DCFs, Hardware... all known good

Now load the known working 2012 DCF onto the known working 2016 DLD
Let us know what happens

First... Errors... lots of them... like 50
Troubling thing is tho, if you ignore those errors... and clear the basic actual errors... on the next go around... (meaning if you save off then re-upload your DCF)... the errors go away. :shock:

Stuff will work I suspect... it will go operational likely.
But... it wont quite work RIGHT.

This is where I think most people lose the most time.

Prove that an I will give you (or whoever you want) 2 free hours on the phone when you need it most.
Emergency phone call answering... ::::: "FRUCK MAN... OH MAN... RACE IS IN 2 HOURS.... F'ING F'ED"
I will field a few of those calls for you if you have the time to perform a test using the scientific method.

Hypothesis:

Hardware Level - duh.. memory and processors/DSPs
Algorythem Level - DLD... firmware accessing hardware locations
Mapping of Resources, scaling, settings - DCF... identifying, scaling, locating data in locations... stuff like that

Say that in 2012 process X in the DLD required 23 unique pieces of data located at 23 different physical locations
Say that in 2016 process X in the DLD required 28 unique pieces of data located at 23 different physical lcoations
Say that the respective DCF's properly populated those data locations

So the 2012 DCF would only populate 23 of the required 28 unique pieces of data


Theory:

In theory the Sevcon DLD should tightly control the pedigree of the data it is reading. If a location is not "mapped"... then the algorithm should not attempt to use that data. It should revert into some sort of LIMP MODE

Thats what I would do... LIMP MODE

Just enough performance to get a forklift the hell out of the way.
A golf cart up a driveway

Just poor enough performance to be unrideable

I dont think Sevcon is good about reporting this tho....

So I propose that a 2012 DCF on a 2016 DLD will result in an extremely confusing situation where everything goes Operational... but nothing quite works perfect. Like the control loop is hiccupy and crappy and just poor performing...

As if... in LIMP MODE>.... or ... (worse)... in NORMAL mode but reading off stale data.

Prove that for me and I will hook you up later.
I need an actual proof. No anecdotal data.
Either direct personal 100% confidence testimony from a Sevcon Expert (5+ years tuning) or a tightly controlled experiment with

00 = Known Good (12 on 12)
01 = Works Wonky (12 on 16)
10 = Works Good (16 on 12)
11 = Known Good (16 on 16)

Arbitrary files... but the farther they are apart in time the better.
Screen shots of upload errors

Of course... you will be really wanting to start with something simple and known good for this test. Any other noise in the system will make it a moot test.

thanks,
-methods
 
Back
Top