search

fermi-ad / controls

Central repo for reporting bugs, making feature requests, managing RFCs, and requesting seminar topics.
https://www-bd.fnal.gov/controls/
2 stars 0 forks source link

FTP AUTO rate issues #36

Closed awattsFNAL closed 7 months ago

awattsFNAL commented 8 months ago

Fast-time plotting from several Erlang front ends plots nonsense data if the rate is set to AUTO.

awattsFNAL commented 8 months ago

https://www-bd.fnal.gov/Elog/?orEntryId=249347

beauremus commented 8 months ago

Derek says:

I can check mine right now. The only time I run in to problems with AUTO is with snapshot plots on erlang FEs when I select auto on mine it defaults to 200hz (despite supporting 1440). other than that it works fine - but my device supports ftp. maybe the problem is with devices that don't?

Dennis replied:

I think Derek's suggestion is correct. I experimented with the standard devices on clx38e, the system/memory devices don't explicitly support (fast) ftp, and they fail in Auto mode. the guaranteed readable devices do support fast reading, and Auto works fine for. them.

Asking Jim S.:

Our default ftpcode for devices that don't specify anything else is ftpcode=15. Is that not a valid code (any longer)? When it's overridden with ftpcode=1 (e.g. U:sysd7c, cpu usage) or 240 (guaranteed readable) ftp auto works fine. But for default devices with 15, it seems to fail with the 15 -103 errors as noted by the MCR.

nicklausdj commented 8 months ago

I can fix (have fixed, but not pushed) this by changing the default erlang device ftpcode so that it sets the DPM15Hz (using gets32) by default. Because this is what is needed by these devices who don't have any explicit FTP fast support. This will negatively impact any driver who does support 15Hz fast FTP and is expecting to get the 15Hz ftpcode set by default. So, @derekste @bigsamich @d4vebr4cey and Kevin, in your C driver initializations, you have an attr list. Do you give the full spect with ftp and snap frequencies, or do you use the abbreviated one with just {type, maxPlotEls,Name,Description}? If the abbreviated one, you're counting on the framework's 15Hz fast default.

beauremus commented 8 months ago

I vaguely remember that the PiVac readings only support 1Hz and come through an Erlang front end. Will choosing 15Hz as a default impact these devices?

ksmartin-fnal-gov commented 8 months ago

For the attr for devices that support 1440Hz FTP I use the full attr spec. For other devices I use the abbreviated attr spec.

derekste commented 8 months ago

my spec looks like this for my 1440Hz FTP / 10kHz SNP device: {'Float', 4, intensityRead, "intensity device / reading attribute", 1440, 10000 },

d4vebr4cey commented 8 months ago

I have one like Derek ( ... 1440, 10000 } ) None abbreviated.
The ftp/snp code I have deployed isn't being used at the moment, so no urgency from me.

awattsFNAL commented 7 months ago

@nicklausdj plans to push new code to Erlang front ends tomorrow at 1000 pending any complaints at the 0900 AD/Ops meeting.

nicklausdj commented 7 months ago

As promised above, 3 weeks ago, I have fixed this by changing the default erlang device ftpcode so that it sets the DPM15Hz (using gets32) by default. With change: https://cdcvs.fnal.gov/redmine/projects/acsys-fe/repository/revisions/cd10e12ea4c59654a6906b8c0444ad2411715426

If you want fast 15Hz or faster, you'll have to set the ftpcode or snapcode in your attr list for the device drivers.