RE: motor record: continuously update limit switches

[Mark Rivers <rivers@cars.uchicago.edu>]

I would replace

(char) NULL

with

NULL 

The (char *) is not needed. NULL is defined to be ((void *)0) in C code, and 0 in C++ code.  Both should work fine in that context and not generate warnings.

Mark



-----Original Message-----
From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Ron Sluiter
Sent: Friday, August 09, 2013 9:13 AM
To: Williams Jr., Ernest L.; Konrad, Martin
Cc: tech-talk@aps.anl.gov
Subject: Re: motor record: continuously update limit switches

Hello Ernest,

No one has checked anything into the motor module since August 2nd, so,
no, those changes have not been applied.

Hello Martin,

Looking at the differences between the github and SVN versions of the motor
module, I see lots of lines with,

> 290c290
> <       send_mess(card, buff, (char) NULL);
> ---
> >       send_mess(card, buff, (char *) NULL);

We are not getting warnings on these lines and we should.
What platform and compiler are you using where you see these warnings?

Ron

On 8/8/2013 6:19 PM, Williams Jr., Ernest L. wrote:
> Hi,
>
> Have these changes been applied to SVN repository for the motor module?
> I was hoping that we could pull your bug fixes from SVN HEAD
>
> Cheers,
> Ernest
>
> -----Original Message-----
> From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Konrad, Martin
> Sent: Thursday, August 08, 2013 7:55 AM
> To: sluiter@aps.anl.gov; mooney@aps.anl.gov; sullivan@aps.anl.gov
> Cc: tech-talk@aps.anl.gov
> Subject: Re: motor record: continuously update limit switches
>
> Dear MotorRecord maintainers,
> you can find my fix for the issue here:
>
> https://github.com/mark0n/motorRecord
>
> The repository also includes patches to eliminate some compiler warnings. Feel free to cherry pick.
>
> Please let me know if you have any concerns regarding the changes I made.
>
> Thanks,
>
> Martin
>
> On 07/29/2013 03:18 PM, Konrad, Martin wrote:
>> Hi,
>>> I tested the OMS-58 and MSTA does update if the limit is disconnected
>>> and STUP is set to 1.
>> Mark, thanks for providing these details. With your information I was
>> able to track the issue further down:
>> Even with the "sendMsg = false;" line commented out in the device
>> support, the MSTA field does not show a change in the limit-switch
>> status while the motor is stopped (as far as I can see commenting out
>> this line has no effect on the behavior at all).
>>
>> Sniffing the TCP connection between the IOC and the motor controller I
>> learned that the issue is caused by the behavior of the motor
>> controller which only transmits some sort of a "limit switch hit while moving"
>> status as a response to the TAS (transmit axis data) command. In other
>> words: The limit status in this message is not updated while the motor
>> is stopped and triggering STUP is pretty useless (at least regarding
>> the limit switches)...
>>
>> Nevertheless it is possible to read out the state of the limit inputs
>> with the TLIM (transmit limits) or LIMFNC (input function for limit
>> inputs) commands. Here is an example:
>> # all limit switches in "ok" position:
>>> TAS
>> *TAS0000_0100_0000_0001_0000_0000_0000_0000
>>> TLIM
>> *TLIM110
>>> LIMFNC
>> *LIMFNC1-R POS LIMIT INPUT       - STATUS ON
>> *LIMFNC2-S NEG LIMIT INPUT       - STATUS ON
>> *LIMFNC3-T HOME LIMIT INPUT      - STATUS OFF
>>
>> # negative limit switch pressed (while motor stopped):
>>> TAS
>> *TAS0000_0100_0000_0001_0000_0000_0000_0000
>>> TLIM
>> *TLIM100
>>> LIMFNC
>> *LIMFNC1-R POS LIMIT INPUT       - STATUS ON
>> *LIMFNC2-S NEG LIMIT INPUT       - STATUS OFF
>> *LIMFNC3-T HOME LIMIT INPUT      - STATUS OFF
>>
>> As far as I can see the PC6K device support should use one of TLIM or
>> LIMFNC to determine the status of the limit switches. Can anyone of
>> the maintainers confirm that? - I don't want to make changes to the
>> code that do not have a chance to be included into the next version of
>> motor record...
>>
>> Thanks for your help,
>>
>> Martin
>>
>>
>>
>