Experimental Physics and
Industrial Control System

[email protected] · Wed, 12 Mar 2014 17:43:29 +0100

Hi Mitch,

OK, I added another 500ms delay before the init string.

Thanks
Jens
_______________________________
Jens Eden
Physikalisch-Technische Bundesanstalt
Albert-Einstein-Straße 15
12489 Berlin

Tel +49 30 3481-7160

Von:    "D'Ewart, J. Mitch" <[email protected]>
An:     Jens Eden <[email protected]>, "Luchini, Kristi L." 
<[email protected]>, 
Kopie:  "[email protected]" <[email protected]>
Datum:  11.03.2014 17:50
Betreff:        RE: MAXv model-3 driver -  omsMAXvConfig  problem

Hi Jens,

We've noticed the same thing with one addition. - we also had to add a 
delay before the init string (after the AM SA;).  Some of the commands 
were not being setup properly if they were sent immediately after the "AM 
SA;" command.

Mitch D'Ewart

________________________________________
From: [email protected] [[email protected]] On 
Behalf Of Jens Eden [[email protected]]
Sent: Monday, March 10, 2014 3:16 AM
To: Luchini, Kristi L.
Cc: [email protected]
Subject: Re: MAXv model-3 driver -  omsMAXvConfig  problem

Hi Kristi,

I noticed that the "LT" command in the init string is not always processed 
properly.
Varying the order of commands in the init string shows different results.
The latest MAXv driver (https://subversion.xor.aps.anl.gov/synApps/motor/) 
has a 500ms delay
to workaround this problem. That did it my case.

Jens

Am 07.03.2014 17:59, schrieb Luchini, Kristi L.:
> Hi ,
>
> Below is an email that Mitch sent to the manufacturer, pro-dex this 
morning , that has  more details.
>
> I'm not sure, but I suspected that the problem is setting the 
configuration,  I don't think there's a read-back of the configuration in 
omsMAXvConfig() that verifies the setting request, and then issues an 
error message if there's a mismatch.  Mitch's system setup is different 
than mine, but the  result seems to be the same.
>
> I recall that Arturo had said this problem didn't occur with the VME 
MAXv driver, but I can test this in development.
> In my case, which occurred a few months ago, during the upgrade of 
production application, to
> 1) the new motor module
> 2)  asyn MAXv driver,
> 3) from CAMAC to VMS
> 4) in some instances, newly installed (if not new) hardware, like driver 
controllers, encoders and such
>
>   the limit switches, as far as I know were not disconnected, as they 
were in Mitch's case.  I will try to reproduce this problem
>   today  in development, and see if I can provide more details. I hope 
this helps.
>
> Regards,
> - Kristi
>
> -----Original Message-----
> From: D'Ewart, J. Mitch
> Sent: Friday, March 07, 2014 8:17 AM
> To: [email protected]
> Cc: Williams Jr., Ernest L.; Oven, Ziga; Luchini, Kristi L.
> Subject: MAXv Configuration
>
> Hi Reto,
>
> I'm working the MAXv and have noticed some odd behavior.  I am using the 
MAXv (OMS Firmware Version is: /MAXv-8000 ver:1.44, s/n:001457, FPGA:B6:A7 
BOOT:1.3 - Oregon Micro Systems) with normally closed limit switches.  On 
boot up I send an initialization string to the MAXv:
>
> "AX LTH PSM; AY LTH PSO"
>
> I noticed that with the limit switches plugged in (NC) the LT command 
does not get processed properly ("AX LT?" returns "=l").  However if the 
limit switches are not plugged in "AX LT?" reports "=h".
>
>
> I found that the driver sends "AM SA;" immediately before the Init 
string.  Playing around with it a bit I found that if I send a string "AM 
SA; AX LTH PSM; AY LTH PSO" with limits connected I get "AX LT?" "=l".  If 
I send the same command string with limits disconnected I get "AX LT?" 
"=h".
>
> Does the "AM SA;" flush some sort of command queue?  Why does the limit 
switch being connected matter?  Why isn't the "PS" command affected, are 
there any other axis commands that could respond the same way?  What is 
the best way to handle this, put a delay after "AM SA;"?  Thanks,
>
> Mitch D'Ewart
>
> -----Original Message-----
> From: Mark Rivers [mailto:[email protected]]
> Sent: Friday, March 07, 2014 4:18 AM
> To: Luchini, Kristi L.; [email protected]
> Subject: RE: MAXv model-3 driver - omsMAXvConfig problem
>
> Can you be more specific about what you mean by "the axis configuration 
settings don't always seem to stick for every axis"?
>
> Do  you mean they are not restored correctly after a reboot?  Or do they 
get lost while the IOC is running?
>
> Mark
>
> ________________________________________
> From: [email protected] [[email protected]] on 
behalf of Luchini, Kristi L. [[email protected]]
> Sent: Thursday, March 06, 2014 6:48 PM
> To: [email protected]
> Subject: MAXv model-3 driver -  omsMAXvConfig  problem
>
> Hello,
>
> We have seen a problem with  the MAXv omsAsyn support,  where the axis 
configuration settings don't always seem to Stick for every axis. We have 
a temporary workaround, where to use the MAXv command "APP" which saves 
the configuration settings as the Power-up default.
>
> Has anyone implemented a solution to this problem?
>
> Details:
> EPICS R4.13.12
> RTEMS-R4.9.4
> MVME6100
> MAXv-8000  FW 1.44
>
>   - Regard,
>    Kristi
>
>
>
>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System