ecs@netbloc.com: 580: Re: [ecs] Fwd: RE: Ocelot problem

Subject:
From:
Date:

Re: [ecs] Fwd: RE: Ocelot problem
Mark Gilmore
Fri, 23 Jan 2004 10:14:22 -0800

Fri, 23 Jan 2004 10:14:22 -0800

but what is the email addr ??

At 12:52 PM 1/23/2004 -0500, you wrote:

>I am trying to re-register my software but something appears to be wrong
>with the email address.  I'm getting a message back that it was
>undeliverable.  Is there a new email address that I should be using?
>----- Original Message -----
>From: "Mark Gilmore" <mark1@markgilmore.net>
>To: <ecsl@netbloc.com>; <ecs@netbloc.com>
>Sent: Thursday, January 22, 2004 11:27 AM
>Subject: [ecs] Fwd: RE: Ocelot problem
>
>
> > Hi everyone,
> > If you are using an Ocelot with digital-input modules (SECU-16/SECU-16I),
> > and have ever seen "suspicious" Digital-Input values, you need to be aware
>of
> > the following:
> >
> > >Date: Thu, 22 Jan 2004 08:21:33 -0800
> > >To: "Reynolds,Martin" <martin.reynolds@gartner.com>
> > >From: Mark Gilmore <mark1@markgilmore.net>
> > >Subject: RE: Ocelot problem
> > >Cc: adiinfo@appdig.com
> > >
> > >WOW - You have a good eye !
> > >And now I think I know what's happening:
> > >A lone FF denotes that an "I/O change has been detected".
> > >My money says that this FF and the "extra" FF below are one in the same.
> > >To speculate further: An Ocelot interrupt-service-routine is transmitting
>this
> > >byte without waiting for the completion of the packet currently being
> > >transmitted.
> > >It may not even be looking to see if a packet transmission is in progress
> > >at all.
> > >This looks like a very serious bug, as it corrupts all module states
> > >reflected in the corrupted packet.
> > >And you may be the first to find it, given your large number of modules.
> > >I am forwarding this to Applied Digital.
> > >Please follow up by telling them what modules you are using (and what rev
> > >of the Ocelot).
> > >
> > >Here is a snapshot of the problem (for Applied Digital):
> > >
> > >GOOD response:
> > >ExCmd:TX: c8 32 0 0 0 0 0 fa
> > >ExCmd:RX:
> > >InpSrv: 6 0 6 a6 0 9e 0 8f 0 a6 0 a2 0 ac 0 ab 0 af 0 5f 0 ff 0 ff 0 ab 0
> > >b3 0 0
> > >          0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > > 0 0 0 0
> > >          0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > > 0 0 0 0
> > >          0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > > 0 0 0 0
> > >          0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > > 0 0 0 0
> > >          0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > > 0 0 0 0
> > >          0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > > 0 0 0 0
> > >          0 0 0 0 0 0 0 0 0 0 0 0 0
> > >
> > >BAD response (FF inserted after 6 0 6):
> > >ExCmd:TX: c8 32 0 0 0 0 0 fa
> > >ExCmd:RX:
> > >InpSrv: 6 0 6 ff a6 0 9e 0 8f 0 a6 0 a2 0 ac 0 ab 0 af 0 5f 0 ff 0 ff 0
>ab
> > >0 b3 0
> > >          0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > > 0 0 0 0
> > >          0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > > 0 0 0 0
> > >          0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > > 0 0 0 0
> > >          0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > > 0 0 0 0
> > >          0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > > 0 0 0 0
> > >          0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > > 0 0 0 0
> > >          0 0 0 0 0 0 0 0 0 0 0 0 0
> > >
> > >
> > >At 07:53 AM 1/22/2004 -0800, you wrote:
> > >
> > >>Agreed. I see now that there is an extra FF inserted into the stream,
> > >>immediately after the 6-0-6 header (i.e. at byte 4). I'll start chasing
> > >>ADI. It has to be either a firmware problem inside the Ocelot, or a
> > >>communications link issue.
> > >>
> > >>Thanks for the help, the loggin on the Ocelot is really useful.
> > >>
> > >>-----Original Message-----
> > >>From: Mark Gilmore [mailto:mark1@markgilmore.net]
> > >>Sent: Thursday, January 22, 2004 7:37 AM
> > >>To: Reynolds,Martin
> > >>Subject: Re: Ocelot problem
> > >>
> > >>Hi Martin,
> > >>I haven't taken the time to parse this packet, but if the "suspicious"
> > >>devices work at all,
> > >>then ECS is parsing the packets properly (and hence, the Ocelot is
> > >>really reporting some as "Off").
> > >>It's the same logic for all: If it works once, it works always.
> > >>I think there is a failure or bug in the Ocelot or SECU-16.
> > >>You might try removing all modules *but* the problematic SECU-16.
> > >>If it then fails, the SECU-16 is the #1 suspect.
> > >>If it then does *not* fail, then the Ocelot firmware is suspect (as it
> > >>may be having problems servicing "too many" modules).
> > >>
> > >>
> > >>---
> > >>Incoming mail is certified Virus Free.
> > >>Checked by AVG anti-virus system (http://www.grisoft.com).
> > >>Version: 6.0.560 / Virus Database: 352 - Release Date: 1/8/2004
> > >
> > >Mark Gilmore
> > >http://OmnipotenceSoftware.com
> >
> > Mark Gilmore
> > http://OmnipotenceSoftware.com
> >
>
>
>----------------------------------------------------------------------------
>----
>
>
> >
> > ---
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.560 / Virus Database: 352 - Release Date: 1/8/2004
> >
>
>
>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.560 / Virus Database: 352 - Release Date: 1/8/2004

Mark Gilmore
http://OmnipotenceSoftware.com


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.560 / Virus Database: 352 - Release Date: 1/8/2004