Re: Checksum for StreamDevice input with regular expression

[Zimoch Dirk via Tech-talk <tech-talk at aps.anl.gov>]

Hi Keith,

I have pushed an update which should fix the "checksum after regsub" problem.
There is no release tag yet but maybe you want to test the fix.

Dirk

On Thu, 2025-05-08 at 12:16 +0000, Baker, Keith (DLSLtd, RAL, LSCI) via Tech-
talk wrote:
> Thanks Dirk.
> I was concerned I was doing something silly, but you’ve confirmed what I’m seeing is as expected.
> It would be good if the checksum only worked on the transmitted data stream, but I can see that means a big change to how the data is processed.
>  
> I’ll stick with what I’ve got or maybe use sCalcout if I get chance to try this. I think I can process the input string more than once so also wondered about using one record to verify the checksum on the raw data, then other records using I/O Intr could reformat the string for their use. I just need to work out how to stop the extra records processing if the checksum fails. Hmm, lots of options to think about.
>  
> Regards,
> Keith
>  
>  
> From: Zimoch Dirk <dirk.zimoch at psi.ch> 
> Sent: 08 May 2025 12:34
> To: Baker, Keith (DLSLtd,RAL,LSCI) <keith.baker at diamond.ac.uk>
> Cc: tech-talk at aps.anl.gov
> Subject: Re: Checksum for StreamDevice input with regular expression
>  
>  	 
> You don't often get email from dirk.zimoch at psi.ch. Learn why this is important 
>  
> Hi Keith
>  
> Yes, the regsub modifies the input buffer on which the checksum is calculated. I never thought about that case. It would make sense of course to calculate the checksum on the original input. Not quite sure how to implement that best, though. I would need to keep the original around for any potential checksum while using the modified string for anything else. That means I need to go away from in-place substitution and have to handle checksums different from all other formats.
>  
> For the time being, I see two work-arounds: 1. ignore the checksum, as you did, or 2. post-process the strings externally, for example in an sCalcout record.
>  
> Dirk
> 
> 
> > Am 08.05.2025 um 13:09 schrieb Baker, Keith (DLSLtd, RAL, LSCI) via Tech-talk <tech-talk at aps.anl.gov>:
> > 
> > 
> > Hello.
> > I am trying to read in a datetime string, format YYMMDDhhmmss, but would prefer it in a more human readable format such as
> > YY-MM-DD hh:mm:ss
> >  
> > My protocol file is fine if I just read the string as YYMMDDhhmmss and the checksum passes.
> > Then I can insert the extra characters with a regular expression to give the string I want but the checksum now fails.
> > I am forced to omit the checksum and just ignore extra input.
> >  
> > Is this the expect behaviour or might I be doing something wrong?
> > If so, can someone suggest a more elegant solution for the format conversion instead of a regular expression, perhaps with an sCalcout record?
> >  
> > I’m sure someone will ask for my code so here it is. I’m actually using redirection to put the date and time into two separate records, $1:DATE and $1:TIME. I’ve shown the evolution of my protocol attempts.
> >  
> > readTime {
> >     out BEL "01ZR \$CS" ETX;
> > # Basic input with no reformatting.
> > #    in BEL "01ZR","%(\$1:DATE)6s%(\$1:TIME)6s\$CS" ETX;
> >  
> > # Next line works but actually does nothing in the regular expression.
> > #    in BEL "01ZR","%#/([0-9]{2})([0-9]{2})([0-9]{2})([0-9]{2})([0-9]{2})([0-9]{2})/\1\2\3\4\5\6/%(\$1:DATE)6s%(\$1:TIME)6s\$CS" ETX;
> >  
> > # Next line gives a checksum error.
> > #    in BEL "01ZR","%#/([0-9]{2})([0-9]{2})([0-9]{2})([0-9]{2})([0-9]{2})([0-9]{2})/\1:\2:\3\4-\5-\6/%(\$1:DATE)8s%(\$1:TIME)8s\$CS" ETX;
> >  
> > # So this is my best solution so far but omitting the checksum.
> >     in BEL "01ZR","%#/([0-9]{2})([0-9]{2})([0-9]{2})([0-9]{2})([0-9]{2})([0-9]{2})/\1:\2:\3\4-\5-\6/%(\$1:DATE)8s%(\$1:TIME)8s";
> >     ExtraInput = Ignore; #Suspect checksum calculated after regex so will not match input.
> > }
> >  
> > If I can get the regular expression to work with a checksum, maybe someone could also suggest a more elegant regular expression.
> > Thanks,
> > Keith Baker
> > Diamond Light Source Ltd
> > 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.
> 
> 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.