Experimental Physics and
Industrial Control System

<[email protected]> · Tue, 22 Jun 2010 17:18:37 +0100

Hi Ron,

Apologies - it seems we are already using the latest driver.  I think we
must have done a patch before the official release.  Actually there
isn't a release 2-5 listed on the synApps vme page as far as I can see?
Anyway the drvIK320.c source file we are using has the latest change
history comment dated 2007/03/02.

Thanks,
Emma

> -----Original Message-----
> From: Ron Sluiter [mailto:[email protected]]
> Sent: 22 June 2010 16:20
> To: Pratt, Linda (DLSLtd,RAL,DIA)
> Cc: [email protected]; Shepherd, Emma (DLSLtd,RAL,DIA);
> [email protected]
> Subject: Re: Problems configuring 4 IK320 cards
> 
> Hello Linda,
> 
> I made several changes to the IK320 driver that were released with VME
> module R2-5.
> I suggest you update to VME module R2-5 or replace the copy of
> drvIK320.c in your
> VME R2-4-4 module with the one from R2-5.  After briefly reviewing the
> changes I
> made to the driver, the 2nd option looks doable, but no guarantees..
> 
> There have been no changes to this driver since the above mentioned
> modifications I made
> in late 2006.  We use the IK320 board here (APS) a fair amount without
> problems, so I am
> hopeful that the updated version will resolve the problems you are
> experiencing.  If not, let me
> know.
> 
> Ron
> 
> [email protected] wrote:
> > We are having problems configuring 4 IK320 cards to read the 4
> readheads
> > from each of 2 Heidenhain RON905 encoders.
> > We have an existing system which does this successfully but we are
> > having difficulty setting up the second one.
> > We seem to be going backwards and would appreciate help diagnosing
> the
> > problem.
> >
> > We are using EPICS 3.14.8.2.
> > We are using the IK320 driver from the vme module in synapps,
release
> > R2-4-4
> >
> > We have not managed to get 4 IK320 cards into 2 groups of 2 to
> > successfully work together with EPICS.
> > Nor do we have them interrupt with updates to the encoder value
> during
> > motion.
> > The system does not seem to be behaving consistently as we make
> changes.
> >
> > In the first configuration, we used the 4 cards in slots 4&5 and 7&8
> > with the dip switches set as they were supplied.
> > The crate also contains an OMS motion control card in slot 6.
> > The crate also contained a Hytec carrier card with 3 ipacs in slot
9.
> >
> > IK320 settings :
> > 0x81/0x81 0x82/0x82 0x83/0x83 0x84/0x84
> >
> > We had the IK32card templates set up correctly, but the group
> templates
> > were set up incorrectly.
> >
> > In this configuration it was possible to read the card encoder
values
> on
> > all 4 cards, but the cards were not interrupting with updates as the
> > axes moved.  The cards were not set on boot.
> >
> > To get the groups set up and to attempt to get the interrupts
> working,
> > we changed the card settings to match the other system we have which
> is
> > working (and rebuilt the database with the new settings).
> >
> > 0xC1/0xC1 0xC2/0xC2 0xA1/0x80 0xA2/0x81
> >
> > This time the card and group templates we used were consistent.
> >
> > Unfortunately this configuration caused clashes in interrupt vector
> with
> > the Hytec cards.
> > We therefore attempted to make changes to avoid this clash.
> >
> > 0xE1/0x80 0xE2/0x81 0xC1/0x82 0xC2/0x83
> >
> > This caused error messages about uninitialized interrupt vector 255,
> > which wisdom on the internet suggests is caused by something writing
> > to the wrong address.
> >
> > Therefore the Hytec card was removed from slot 9 to try to make
> progress
> > and all setup and records for it scrapped from the IOC build and
> > returned to the configuration for the sister system.
> >
> > With
> > 0xC1/0xC1 0xC2/0xC2 0xA1/0x80 0xA2/0x81
> >
> > We got this:
> >
> > drvIK320 starting irq logger...
> >
> > drvIK320: doing POST on 0xc1/0xc1
> >
> > drvIK320: doing POST on 0xc2/0xc2
> >
> > drvIK320: doing POST on 0xa1/0x80
> >
> > filename="../drvIK320.c" line number=1218
> >
> > Timeout!
> >
> > filename="../drvIK320.c" line number=270
> >
> > IK320 board failure.
> >
> > filename="../drvIK320.c" line number=270
> >
> > IK320 board failure.
> >
> >
> > However, suspecting a faulty bit (the 2s bit) in one of the
> dipswitches
> > on the third board we tried this.
> > 0xC1/0xC1 0xC2/0xC2 0xA3/0x83 0xA2/0x81
> >
> > In this configuration POST was successful and boards 2-4 reported
> their
> > encoder values on boot.
> > However board 1 could not be read.
> > The console gave an error message about the card being busy, however
> > many times you tried to do the read.
> >
> > We also tried
> > 0xC1/0x81 0xC2/0x82 0xA3/0x83 0xA2/0x84
> >
> > Finally, we went back to the original configuration and defined the
> > groups appropriately.
> > 0x81/0x81 0x82/0x82 0x83/0x83 0x84/0x84
> >
> > The POST was OK, but card 3 could not be read, still giving the busy
> > message.
> > We decided to try to set up the groups how they should be.
> > 0x81/0x81 0x82/0x82 0xA3/0x83 0xA4/0x84
> >
> > Again POST was OK but card 3 could not be read.
> >
> > We tried swapping cards 3 and 4 to see if card 3 is faulty in some
> way.
> > Card 3 still
> > cannot be read (was card 4).  Card 4 (was card 3) is the only one
> that
> > sets its value on boot. Cards 1 and 2 can have their encoders read.
> > This is evidence against the stuck 2s bit dipswitch theory.
> >
> > Here is an example of the "busy message"
> >
> > BL10I-MO-IOC-01 -> filename="../devIK320.c" line number=1002
> > ik320ReadAi() entering...
> >
> > filename="../devIK320.c" line number=1037
> > ik320ReadAi() sending request (1st phase) failed...
> >
> > filename="../devIK320.c" line number=1058
> > ik320ReadAi() exit (status 4090001).
> >
> > IK320 card busy PV: BL10I-OP-PGM-01:MIR:ENC1:RAW ik320ReadAi()
> >
> > We're struggling to know what to try next.
> >
> > Thanks very much,
> >
> > Linda Pratt
> > Software Systems Engineer
> > Controls Department
> > [email protected]
> > +44 (0)1235 778058
> > www.diamond.ac.uk
> > Diamond Light Source Ltd
> > Diamond House
> > Harwell Science and Innovation Campus
> > DIDCOT
> > Oxfordshire
> > OX11 0DE
> > UK
> >
> >

-- 
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System