Thanks Michael, and Arman.
Just had a quick check, and found all packages for Jessie are already in staging.
That helps a lot already.
Guobao
On 8/20/15 7:50 PM, Arkilic, Arman wrote:
I can help with the mirror in BNL. Let me know what you've in mind and how I can proceed.
On Aug 20, 2015, at 7:44 PM, "[email protected]" <[email protected]> wrote:
Send Tech-talk mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://mailman.aps.anl.gov/mailman/listinfo/tech-talk
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Tech-talk digest..."
Today's Topics:
1. Re: EPICS Debian package server (Michael Davidsaver)
2. RE: Fast, reliable remote I/O in 2015 (Mark Rivers)
----------------------------------------------------------------------
Message: 1
Date: Thu, 20 Aug 2015 17:53:37 -0400
From: Michael Davidsaver <[email protected]>
To: [email protected]
Subject: Re: EPICS Debian package server
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
This is a good question to which I don't have a good answer. I
anticipate losing access to http://epics.nsls2.bnl.gov/debian/ shortly
and it's not clear who at BNL would pick up this work. The package
source is all up on github (https://github.com/epicsdeb). I've thought
about the possibility of lab-agnostic hosting in the past, but haven't
had the time or resources to follow through (the current binary repo
weights in at ~11 GB).
If anyone has any ideas, would like to support, contribute, or take
over, this work, please let me know.
atm. I think I've updated/built most of the package set for debian 8
(jessie).
On 08/20/2015 04:57 PM, Shen, Guobao wrote:
Hi,
Is there any site planning to bring all EPICS Debian packages
including EPICS base to the latest release (I mean Jessie for now)?
Is there any plan in our community?
Thanks,
Guobao
------------------------------
Message: 2
Date: Thu, 20 Aug 2015 23:43:34 +0000
From: Mark Rivers <[email protected]>
To: "'Gomella, Andrew (NIH/NHLBI) [F]'" <[email protected]>,
"'[email protected]'" <[email protected]>
Subject: RE: Fast, reliable remote I/O in 2015
Message-ID:
<70AE7462E7AD054C89DCBA45343D499A6592F7DC@CARSMAIL2.CARS.APS.ANL.GOV>
Content-Type: text/plain; charset="us-ascii"
Folks,
I changed the implementation slightly. The command is now called asynSetMinTimerPeriod(double period), and it is now located in asyn/miscellaneous/asynShellCommands.c.
This is from the asyn release notes:
**************************
Added new command asynSetMinTimerPeriod, and corresponding C function. This command is currently only implemented on the WIN32 architectures, and simply prints an error message on all other architectures. It allows reducing the minimum time for epicsThreadSleep() from the default of 10 ms to the minimum supported Windows system value. On most systems this is 1 ms. Note that epicsThreadSleepQuantum() does not seem to report the correct value whether or not this function is called. On my system it always reports 0.0156 seconds. Note also that this function really has nothing to do with asyn, and the equivalent functionality should probably be moved into EPICS base at some time.
**************************
I tested the new functionality with simDetector in areaDetector. Previously on Windows the simDetector could generate at most 100 frames/s (1024x1024 8-bit mono) because of the 10 ms minimum value for epicsThreadSleep. By adding the command asynSetMinTimePeriod(0.001) to the startup script it can now generate 1000 frames/s. This is a nice improvement, because it allows testing the performance of plugins under high-load conditions.
Mark
From: Mark Rivers
Sent: Thursday, August 20, 2015 3:10 PM
To: 'Gomella, Andrew (NIH/NHLBI) [F]'; '[email protected]'
Subject: RE: Fast, reliable remote I/O in 2015
Folks,
I said yesterday that the minimum value for epicsThreadSleep on Windows is 10 ms. I did some research and found that Windows provides functions to change the minimum time period. They are
timeGetDevCaps(TIMECAPS *pTimeCaps, sizeof(TIMECAPS)) Returns the minimum and maximum allowed values for the timer period
timeBeginPeriod(UINT periodMs) Sets the new timer period in ms
timeBeginEnd(UINT periodMs) Reverts to the previous timer period
The minimum and maximum allowed values for the period are said to potentially depend on the hardware and version of Windows. Testing with the timeGetDevCaps function on my system I found that the minimum value is 1 ms, and the maximum value is 1 second (1000000 ms).
It seems to me that is very useful to be able to change the minimum time to be able to poll faster than 100 Hz on Windows.
This should probably be added to EPICS base somehow, but since that has a long lead time and is out of my control I have added the following to asyn/miscellaneous.
asynSetWIN32PeriodMin.h
asynSetWIN32PeriodMin.c
asynSetWIN32PeriodMin.dbd
These define and implement this function:
epicsShareFunc int asynSetWIN32PeriodMin(double period);
There is a corresponding iocsh command.
I changed the driver for the Measurement Computing USBCTR device to allow the poll time to be specified in the constructor and iocsh command, rather than hard-coding 0.01 seconds.
I added the new command to set the minimum poll time to 0.001 seconds to the startup script:
## Set the minimum sleep time to 1 ms
asynSetWIN32PeriodMin(0.001)
I then tested with the USBCTR poll time set to 0.01 seconds, and to 0.001 seconds:
This is the output when the poll time was set to 0.01 seconds. I changed the camonitor command to print incremental timestamps, since then I don't need to do the math to get the latency.
USBCTRConfig("$(PORT)", 0, 2048, .01)
USBCTR:Bo1 ( +11.307122) High
USBCTR:Bi3 ( +0.002358) High
USBCTR:Bo1 ( +0.924946) Low
USBCTR:Bi3 ( +0.007908) Low
USBCTR:Bo1 ( +0.551547) High
USBCTR:Bi3 ( +0.008925) High
USBCTR:Bo1 ( +0.422266) Low
USBCTR:Bi3 ( +0.006337) Low
USBCTR:Bo1 ( +0.785057) High
USBCTR:Bi3 ( +0.006451) High
USBCTR:Bo1 ( +0.329230) Low
USBCTR:Bi3 ( +0.002209) Low
USBCTR:Bo1 ( +0.397546) High
USBCTR:Bi3 ( +0.007211) High
USBCTR:Bo1 ( +0.375701) Low
USBCTR:Bi3 ( +0.008939) Low
USBCTR:Bo1 ( +0.342875) High
USBCTR:Bi3 ( +0.008925) High
USBCTR:Bo1 ( +0.670906) Low
USBCTR:Bi3 ( +0.002325) Low
USBCTR:Bo1 ( +0.469354) High
USBCTR:Bi3 ( +0.002250) High
USBCTR:Bo1 ( +0.317454) Low
USBCTR:Bi3 ( +0.002241) Low
USBCTR:Bo1 ( +0.340839) High
USBCTR:Bi3 ( +0.008931) High
USBCTR:Bo1 ( +0.351916) Low
USBCTR:Bi3 ( +0.002397) Low
USBCTR:Bo1 ( +0.670341) High
USBCTR:Bi3 ( +0.002352) High
USBCTR:Bo1 ( +1.863353) Low
USBCTR:Bi3 ( +0.006470) Low
Note that the latencies range from 2.2 ms to 8.9 ms.
I then decreased the poll time to 1 ms.
USBCTRConfig("$(PORT)", 0, 2048, .001)
USBCTR:Bo1 ( +4.444168) High
USBCTR:Bi3 ( +0.002350) High
USBCTR:Bo1 ( +0.429896) Low
USBCTR:Bi3 ( +0.002215) Low
USBCTR:Bo1 ( +0.637965) High
USBCTR:Bi3 ( +0.002354) High
USBCTR:Bo1 ( +0.382533) Low
USBCTR:Bi3 ( +0.002266) Low
USBCTR:Bo1 ( +0.462775) High
USBCTR:Bi3 ( +0.002334) High
USBCTR:Bo1 ( +0.405535) Low
USBCTR:Bi3 ( +0.002379) Low
USBCTR:Bo1 ( +0.374074) High
USBCTR:Bi3 ( +0.002274) High
USBCTR:Bo1 ( +0.416476) Low
USBCTR:Bi3 ( +0.002236) Low
USBCTR:Bo1 ( +0.387610) High
USBCTR:Bi3 ( +0.002334) High
USBCTR:Bo1 ( +0.381446) Low
USBCTR:Bi3 ( +0.002238) Low
USBCTR:Bo1 ( +0.485361) High
USBCTR:Bi3 ( +0.002270) High
USBCTR:Bo1 ( +1.020690) Low
USBCTR:Bi3 ( +0.002287) Low
USBCTR:Bo1 ( +0.443587) High
USBCTR:Bi3 ( +0.002291) High
USBCTR:Bo1 ( +0.342173) Low
USBCTR:Bi3 ( +0.002224) Low
USBCTR:Bo1 ( +0.317371) High
USBCTR:Bi3 ( +0.002335) High
USBCTR:Bo1 ( +0.301346) Low
USBCTR:Bi3 ( +0.002218) Low
USBCTR:Bo1 ( +0.469614) High
USBCTR:Bi3 ( +0.002447) High
USBCTR:Bo1 ( +1.276166) Low
USBCTR:Bi3 ( +0.002375) Low
Now the latencies are always 2.2 to 2.4 ms.
I checked the CPU time being used with both 0.01 and 0.001 timer period. The IOC application was not using a measurable percent of CPU time in either case. More testing would be required to make sure there are no undesired side-effects of decreasing the timer period, but so far it seems fine.
I put some debugging code in the new asyn function, printing out the value epicsThreadSleepQuantum() both before and after changing the timer period:
asynSetWIN32PeriodMin(0.001)
Minimum time=1, maximum time=1000000, sleepQuantum=0.015600
Called timePeriodBegin(1), status=0, sleepQuantum=0.015600
It appears to me that the value of epicsThreadSleepQuantum() on Windows is incorrect. It is reporting 0.0156 seconds both before and after I change the timer period from 0.01 to 0.001, while the values should actually me 0.01 and 0.001.
Mark
From: Mark Rivers
Sent: Wednesday, August 19, 2015 5:48 PM
To: 'Gomella, Andrew (NIH/NHLBI) [F]'; [email protected]<mailto:[email protected]>
Subject: RE: Fast, reliable remote I/O in 2015
Hi Andrew,
With PLCs there are two timescales you need to consider. The first is how quickly the PLC itself can react to the signal, using ladder logic for example. The second is how quickly the change of an input is communicated to EPICS. With the PLCs I have worked with (Allen Bradley SLC-500 and all Modbus PLCS using my EPICS software) the communication with EPICS is done via polling over some communication channel. With the Koyo Modbus PLCs I typically poll at 10 Hz, so the average latency in detecting a transition will be 50 ms and worst-case would be 100 ms. I'm sure it could be polled faster, but I have not tested how fast the PLC can respond. There may be PLCs that can send data automatically to EPICS on a change of input state, but I am not aware of them.
Another option are the USB devices from Measurement Computing. I have support for a number of these here, and all support at least 8 digital I/O bits.
http://cars.uchicago.edu/software/epics/measComp.html
I just did a quick test with the USB-CTR08, which can be used as an EPICS scaler and multi-channel scaler, but also supports 8 digital I/O signals. It only costs $429.
http://www.mccdaq.com/usb-data-acquisition/USB-CTR08.aspx
I connected a binary output to a binary input and then ran camonitor to see how quickly the input changed state when I changed the state of the output via a Channel Access put. I measured this with the camonitor program running on the same computer that is controlling the hardware. Here are the results. I've added annotation after each change that gives the latency.
J:\epics\devel\measComp>camonitor -tc USBCTR:Bo1 USBCTR:Bi3
USBCTR:Bo1 (2015-08-19 17:03:43.873133) High
USBCTR:Bi3 (2015-08-19 17:03:43.877075) High (4 ms)
USBCTR:Bo1 (2015-08-19 17:03:44.505137) Low
USBCTR:Bi3 (2015-08-19 17:03:44.507717) Low (2 ms)
USBCTR:Bo1 (2015-08-19 17:03:45.048369) High
USBCTR:Bi3 (2015-08-19 17:03:45.055462) High (7 ms)
USBCTR:Bo1 (2015-08-19 17:03:45.647819) Low
USBCTR:Bi3 (2015-08-19 17:03:45.650384) Low (3 ms)
USBCTR:Bo1 (2015-08-19 17:03:46.167485) High
USBCTR:Bi3 (2015-08-19 17:03:46.176412) High (9 ms)
USBCTR:Bo1 (2015-08-19 17:03:46.718940) Low
USBCTR:Bi3 (2015-08-19 17:03:46.726020) Low (8 ms)
USBCTR:Bo1 (2015-08-19 17:03:47.238455) High
USBCTR:Bi3 (2015-08-19 17:03:47.242538) High (4 ms)
USBCTR:Bo1 (2015-08-19 17:03:47.901714) Low
USBCTR:Bi3 (2015-08-19 17:03:47.904288) Low (3 ms)
USBCTR:Bo1 (2015-08-19 17:03:48.453459) High
USBCTR:Bi3 (2015-08-19 17:03:48.456179) High (3 ms)
USBCTR:Bo1 (2015-08-19 17:03:49.044768) Low
USBCTR:Bi3 (2015-08-19 17:03:49.047978) Low (3 ms)
USBCTR:Bo1 (2015-08-19 17:03:49.485097) High
USBCTR:Bi3 (2015-08-19 17:03:49.488430) High (3 ms)
USBCTR:Bo1 (2015-08-19 17:03:50.061665) Low
USBCTR:Bi3 (2015-08-19 17:03:50.064231) Low (3 ms)
USBCTR:Bo1 (2015-08-19 17:03:50.558172) High
USBCTR:Bi3 (2015-08-19 17:03:50.560882) High (2 ms)
USBCTR:Bo1 (2015-08-19 17:03:51.022645) Low
USBCTR:Bi3 (2015-08-19 17:03:51.025241) Low (3 ms)
The latency is determined by the polling period, which was 0.01 seconds. That should have led to a 5 ms average latency and 10 ms worst case. That corresponds roughly to what I measured. In this configuration the IOC was using less than 1% of the CPU time on the system.
I am sure that the system can poll faster without consuming too many resources. Unfortunately Windows has a minimum time for epicsThreadSleep of 0.01 seconds, so it cannot poll any faster on Windows without coming up with some other delay mechanism. There are Linux drivers available for some Measurement Computing devices, but no EPICS support for those drivers since they use different libraries.
Measurement Computing also offers a new high-speed 32-bit Digital I/O module for $499:
http://www.mccdaq.com/usb-data-acquisition/USB-DIO32HS.aspx
This device can stream the input values at up to 8 million samples/sec, so it has much faster response. You would need to modify the driver to handle this data, but I already have drivers that handle streaming analog data.
Mark
From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Gomella, Andrew (NIH/NHLBI) [F]
Sent: Wednesday, August 19, 2015 4:06 PM
To: [email protected]<mailto:[email protected]>
Subject: Fast, reliable remote I/O in 2015
Hi Everyone,
We are in need of some simple, yet fast remote I/O solutions in our lab. Namely we are looking digital inputs and outputs accessible as EPICS PVs for various fast synchronization tasks.
Our current solution has been to use National Instruments DAQ boards which has been relatively unreliable (if the computer shuts off, so does the DAQ; No EPICS support that I know of from any facility; Only well supported by NI with Windows use, their Linux drivers do not work for us) They seem much more suited to isolated measurement tasks, rather than as "always on" hardware controllers.
I imagine most people in the EPICS world would use PLC's for this, as I found in a Tech-Talk thread on essentially the same topic in 2009 : http://www.aps.anl.gov/epics/tech-talk/2009/msg01775.php or use VME crates (it seems there is a gradual trend away from using VME for simple I/O tasks)
We are looking for a simple, reliable solution that in the end results in simply having one record per digital in, one record per digital out. Ideally it would be very fast so we could act quickly on callbacks to input value changes ( <1ms would be ideal but 5ms is acceptable).
We would likely have must of our logic running elsewhere in Python, so we do not necessarily need ladder logic or other embedded software to execute logical tasks (besides maybe what action to take if a watchdog timer fails).
After searching tech-talk I compiled this short list of options, though I am curious if anyone else has better ideas for this specific application since 6 years has passed since some of these threads:
Koyo PLC's with softIOC using the modbus EPICS module
-Mark River's notes here that this allows direct access to memory registers so it can be used as a "simple I/O system" http://www.aps.anl.gov/epics/tech-talk/2009/msg01797.php
Yokogawa PLCs with embedded Linux
- as demonstrated by KEK here: http://www-linac.kek.jp/cont/epics/f3rp61/ and discussed here: http://www.aps.anl.gov/epics/tech-talk/2009/msg01795.php
-Having embedded EPICS on a PLC seems like a very attractive idea.
WAGO or Beckhoff PLCs using EtherCAT as recently described here
-http://www.aps.anl.gov/epics/tech-talk/2014/msg01315.php
(Epics Brick seemed like a great idea when I first read about it then realized it was discontinued in 2008)
I have to note that it seems many PLCs digital inputs are not as fast as we would like (the entire Koyo Click series seems to only guarantee a max response of 10ms for off to on and on to off so that removes this option for us).
I'm sure a lot has changed in the past 6 years, and that I missed some options so any advice would be greatly appreciated.
Thanks in advance,
Andrew Gomella
Imaging Physics Lab, NHLBI, NIH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.aps.anl.gov/pipermail/tech-talk/attachments/20150820/314f7b88/attachment.html>
------------------------------
_______________________________________________
Tech-talk mailing list [email protected]
https://mailman.aps.anl.gov/mailman/listinfo/tech-talk
End of Tech-talk Digest, Vol 9, Issue 267
*****************************************
- Navigate by Date:
- Prev:
Re: EPICS Debian package server Arkilic, Arman
- Next:
Re: EPICS Debian package server Florian Feldbauer
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
<2015>
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: EPICS Debian package server Arkilic, Arman
- Next:
Control room console hardware Rod Nussbaumer
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
<2015>
2016
2017
2018
2019
2020
2021
2022
2023
2024
|
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·