RE: Tech-talk Digest, Vol 9, Issue 263

[Mark Clift <Mark.Clift@synchrotron.org.au>]

Dear Andrew,

The Galil RIO PLC range may also be of interest to you.  Something like the RIO-47300 costs around $500USD has 24 opto isolated digital inputs and same for digital outputs.  There are 8 analog inputs, and 8 outputs with up to 16 bit resolution.  I cannot comment on hardware conversion times on the analogs, but the optos on the digital IO will be fast as they are non-darlington type.   The PLC has a 32 bit risc processor on board.

The same EPICS driver is used for the Galil RIO, and motor controllers.  There is an asynchronous UDP streaming mode with 8 ms updates.  A similar speed TCP poll mode is also available.  Auto connect is supported.  For critical applications the controller could be tuned to give faster updates by changing the clock from the default speed.  

http://www.galilmc.com/plcs/remote-io/rio-47300

And the EPICS driver is here:

https://github.com/motorapp/Galil-3-0/releases/tag/V3-1

Best wishes,

Mark

Dr. Mark Clift
Senior Controls Engineer
Australian Synchrotron
800 Blackburn Road
Clayton 3168
Ph: +613 8540 4264
Fax: +613 8540 4200
Mail: Mark.Clift@Synchrotron.org.au
________________________________________
From: tech-talk-bounces@aps.anl.gov [tech-talk-bounces@aps.anl.gov] on behalf of tech-talk-request@aps.anl.gov [tech-talk-request@aps.anl.gov]
Sent: Thursday, 20 August 2015 23:18
To: tech-talk@aps.anl.gov
Subject: Tech-talk Digest, Vol 9, Issue 263

Send Tech-talk mailing list submissions to
        tech-talk@aps.anl.gov

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
        tech-talk-request@aps.anl.gov

You can reach the person managing the list at
        tech-talk-owner@aps.anl.gov

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Tech-talk digest..."


Today's Topics:

   1. Fast, reliable remote I/O in 2015
      (Gomella, Andrew (NIH/NHLBI) [F])
   2. RE: Fast, reliable remote I/O in 2015 (Mark Rivers)
   3. EPICS base-3.15.2 compilation error for VS Express 2015 on
      Windows 10 (Chu, Paul)
   4. Re: Fast, reliable remote I/O in 2015 (nick.rees@diamond.ac.uk)
   5. cadoubletabwidget (Mezger Anton Christian (PSI))
   6. RE: EPICS base-3.15.2 compilation error for VS Express 2015
      on        Windows 10 (Mark Rivers)


----------------------------------------------------------------------

Message: 1
Date: Wed, 19 Aug 2015 21:06:19 +0000
From: "Gomella, Andrew (NIH/NHLBI) [F]" <andrew.gomella@nih.gov>
To: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Subject: Fast, reliable remote I/O in 2015
Message-ID: <D91A16828A991E4A854EBB36CD0D1D26316A3A@msgb01.nih.gov>
Content-Type: text/plain; charset="iso-8859-1"

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/20150819/3a86b50e/attachment.html>

------------------------------

Message: 2
Date: Wed, 19 Aug 2015 22:47:58 +0000
From: Mark Rivers <rivers@cars.uchicago.edu>
To: "'Gomella, Andrew (NIH/NHLBI) [F]'" <andrew.gomella@nih.gov>,
        "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Subject: RE: Fast, reliable remote I/O in 2015
Message-ID:
        <70AE7462E7AD054C89DCBA45343D499A6592E111@CARSMAIL2.CARS.APS.ANL.GOV>
Content-Type: text/plain; charset="us-ascii"

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: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Gomella, Andrew (NIH/NHLBI) [F]
Sent: Wednesday, August 19, 2015 4:06 PM
To: tech-talk@aps.anl.gov
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/20150819/40349874/attachment.html>

------------------------------

Message: 3
Date: Thu, 20 Aug 2015 04:43:19 +0000
From: "Chu, Paul" <chu@frib.msu.edu>
To: "tech-talk@aps.anl.gov " <tech-talk@aps.anl.gov>
Subject: EPICS base-3.15.2 compilation error for VS Express 2015 on
        Windows 10
Message-ID:
        <f839609b02c6483696e8deb6b004bdc1@EX01.intranet.nscl.msu.edu>
Content-Type: text/plain; charset="utf-8"

Hi all,



When I tried to compile EPICS base 3.15.2 on Windows 10 with MS Visual Studio Express 2015, I got the following error. I tried on VS Express 2010 (with Windows SDK), 2012 and 2013 for Windows 10 and all went through without any problem (for both win32-x86 and windows-x64). VS Express 2015 is the only one with trouble. The first error seems to be caused by ?timespec? redefined (see below). After I commented out the ?timespec? def in the code, there?s another array size exceeds limit error?



I was wondering if anybody else successfully compiled the code with VS Express 2015.



Thanks,

Paul



?

cl -EHsc -GR                -nologo -D__STDC__=0 -D_CRT_SECURE_NO_DEPRECATE -D_C

RT_NONSTDC_NO_DEPRECATE   -Ox -GL -Oy-   -W3 -w44355        -MD -DEPICS_BUILD_DL

L -DEPICS_CALL_DLL -TP  -I. -I../O.Common -I. -I../../../src/libCom/osi/compiler

/msvc -I../../../src/libCom/osi/compiler/default -I. -I../../../src/libCom/osi/o

s/WIN32 -I../../../src/libCom/osi/os/default -I.. -I../../../src/libCom/as -I../

../../src/libCom/bucketLib -I../../../src/libCom/calc -I../../../src/libCom/cvtF

ast -I../../../src/libCom/cppStd -I../../../src/libCom/cxxTemplates -I../../../s

rc/libCom/dbmf -I../../../src/libCom/ellLib -I../../../src/libCom/env -I../../..

/src/libCom/error -I../../../src/libCom/fdmgr -I../../../src/libCom/flex -I../..

/../src/libCom/freeList -I../../../src/libCom/gpHash -I../../../src/libCom/iocsh

-I../../../src/libCom/log -I../../../src/libCom/macLib -I../../../src/libCom/mi

sc -I../../../src/libCom/osi -I../../../src/libCom/pool -I../../../src/libCom/ri

ng -I../../../src/libCom/taskwd -I../../../src/libCom/timer -I../../../src/libCo

m/yacc -I../../../src/libCom/yacc -I../../../src/libCom/yajl -I../../../include/

compiler/msvc -I../../../include/os/WIN32 -I../../../include         -c ../../..

/src/libCom/fdmgr/fdmgr.cpp

fdmgr.cpp

../../../src/libCom/osi/os/WIN32\osdTime.h(21): error C2011: 'timespec': 'struct

' type redefinition

C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt\time.h(39): not

e: see declaration of 'timespec'

make[3]: *** [fdmgr.obj] Error 2

make[3]: Leaving directory `c:/epics/base-3.15.2/src/libCom/O.win32-x86'

make[2]: *** [install.win32-x86] Error 2

make[2]: Leaving directory `c:/epics/base-3.15.2/src/libCom'

make[1]: *** [libCom.install] Error 2

make[1]: Leaving directory `c:/epics/base-3.15.2/src'

make: *** [src.install] Error 2

make: Leaving directory `c:/epics/base-3.15.2'





Sent from Mail<http://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.aps.anl.gov/pipermail/tech-talk/attachments/20150820/a00971b3/attachment.html>

------------------------------

Message: 4
Date: Thu, 20 Aug 2015 06:18:28 +0000
From: <nick.rees@diamond.ac.uk>
To: <andrew.gomella@nih.gov>, <tech-talk@aps.anl.gov>
Subject: Re: Fast, reliable remote I/O in 2015
Message-ID: <ymwyi15l3uxhfe85dhix9s7v.1440051502980@email.android.com>
Content-Type: text/plain; charset=iso-8859-1

Hi Andrew,

The Ethercat option you referenced doesn't use a PLC - it directly connects to the hardware via a spare Ethernet port on a Linux system with an open source Ethercat driver and an EPICS driver we wrote. We typically run the Linux scanning task at 1 kHz and have typical latencies in rhe 1 ms range.

It probably matches your requirements pretty well and I heard of a number of sites who have tried it and reported success.

Cheers,

Nick Rees
Principal Software Engineer           Phone: +44 (0)1235-778430
Diamond Light Source                  Fax:   +44 (0)1235-446713


-------- Original message --------
From: "Gomella, Andrew (NIH/NHLBI) [F]"
Date:19/08/2015 22:08 (GMT+00:00)
To: tech-talk@aps.anl.gov
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


--
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




------------------------------

Message: 5
Date: Thu, 20 Aug 2015 10:17:39 +0000
From: "Mezger Anton Christian (PSI)" <anton.mezger@psi.ch>
To: "mdmoore@aps.anl.gov" <mdmoore@aps.anl.gov>,
        "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Subject: cadoubletabwidget
Message-ID:
        <968FB123AD97E243ABBCB792225412A420DB2F55@MBX214.d.ethz.ch>
Content-Type: text/plain; charset="us-ascii"

Hi  Matt,

you will find a small example in caQtDM_Project/caQtDM_Tests/Display/ TST-CAQTDM-MAIN.ui.

with the designer you can insert a page at the double entry with insert before or after current page (context for cadoubletabwidget)

Hope that helps

Best regards

Anton

__________________________________________
Paul Scherrer Institut
Dr. Anton Christian Mezger
WBGB/103
CH-5232 Villigen PSI

Telefon: +41 56 310 34 06
E-Mail: anton.mezger@psi.ch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.aps.anl.gov/pipermail/tech-talk/attachments/20150820/21acd0c8/attachment.html>

------------------------------

Message: 6
Date: Thu, 20 Aug 2015 13:17:59 +0000
From: Mark Rivers <rivers@cars.uchicago.edu>
To: "Chu, Paul" <chu@frib.msu.edu>, "tech-talk@aps.anl.gov "
        <tech-talk@aps.anl.gov>
Subject: RE: EPICS base-3.15.2 compilation error for VS Express 2015
        on      Windows 10
Message-ID:
        <70AE7462E7AD054C89DCBA45343D499A6592E536@CARSMAIL2.CARS.APS.ANL.GOV>
Content-Type: text/plain; charset="Windows-1252"

This problem has been found for other projects as well, e.g. libusb.  VS2015 time.h now defines timespec.

https://github.com/libusb/libusb/pull/60/files


This is the change from libusb:

 // We *were* getting timespec from pthread.h:
 #if (!defined(HAVE_STRUCT_TIMESPEC) && !defined(_TIMESPEC_DEFINED))
 #define HAVE_STRUCT_TIMESPEC 1
+#if _MSC_VER >= 1900
+#include <time.h>
+#else
 #define _TIMESPEC_DEFINED 1
 struct timespec {
                long tv_sec;
                long tv_nsec;
 };
+#endif
 #endif /* HAVE_STRUCT_TIMESPEC | _TIMESPEC_DEFINED */


The following patch to base/src/libCom/osi/os/WIN32/osdTime.h might work:

#if ! defined(_MINGW) || ! defined(_TIMESPEC_DEFINED)
+#if _MSC_VER >= 1900
+#include <time.h>
+#else
struct timespec {
        time_t tv_sec; /* seconds since some epoch */
        long tv_nsec; /* nanoseconds within the second */
};
+#endif /* _MSC_VER >= 1900 */
+
#endif /* ! defined(_MINGW) || ! defined(_TIMESPEC_DEFINED) */

#endif /* ifndef osdTimeh */







From: tech-talk-bounces@aps.anl.gov [tech-talk-bounces@aps.anl.gov] on behalf of Chu, Paul [chu@frib.msu.edu]

Sent: Wednesday, August 19, 2015 11:43 PM

To: tech-talk@aps.anl.gov

Subject: EPICS base-3.15.2 compilation error for VS Express 2015 on Windows 10










Hi all,

When I tried to compile EPICS base 3.15.2 on Windows 10 with MS Visual Studio Express 2015, I got the following error. I tried on VS Express 2010 (with Windows SDK), 2012 and 2013 for Windows 10 and all went through without any problem (for both win32-x86
 and windows-x64). VS Express 2015 is the only one with trouble. The first error seems to be caused by ?timespec? redefined (see below). After I commented out the ?timespec? def in the code, there?s another array size exceeds limit error?


I was wondering if anybody else successfully compiled the code with VS Express 2015.

Thanks,
Paul

?
cl -EHsc -GR                -nologo -D__STDC__=0 -D_CRT_SECURE_NO_DEPRECATE -D_C
RT_NONSTDC_NO_DEPRECATE   -Ox -GL -Oy-   -W3 -w44355        -MD -DEPICS_BUILD_DL
L -DEPICS_CALL_DLL -TP  -I. -I../O.Common -I. -I../../../src/libCom/osi/compiler
/msvc -I../../../src/libCom/osi/compiler/default -I. -I../../../src/libCom/osi/o
s/WIN32 -I../../../src/libCom/osi/os/default -I.. -I../../../src/libCom/as -I../
../../src/libCom/bucketLib -I../../../src/libCom/calc -I../../../src/libCom/cvtF
ast -I../../../src/libCom/cppStd -I../../../src/libCom/cxxTemplates -I../../../s
rc/libCom/dbmf -I../../../src/libCom/ellLib -I../../../src/libCom/env -I../../..
/src/libCom/error -I../../../src/libCom/fdmgr -I../../../src/libCom/flex -I../..
/../src/libCom/freeList -I../../../src/libCom/gpHash -I../../../src/libCom/iocsh
-I../../../src/libCom/log -I../../../src/libCom/macLib -I../../../src/libCom/mi
sc -I../../../src/libCom/osi -I../../../src/libCom/pool -I../../../src/libCom/ri
ng -I../../../src/libCom/taskwd -I../../../src/libCom/timer -I../../../src/libCo
m/yacc -I../../../src/libCom/yacc -I../../../src/libCom/yajl -I../../../include/
compiler/msvc -I../../../include/os/WIN32 -I../../../include         -c ../../..
/src/libCom/fdmgr/fdmgr.cpp
fdmgr.cpp
../../../src/libCom/osi/os/WIN32\osdTime.h(21): error C2011: 'timespec': 'struct
' type redefinition
C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt\time.h(39): not
e: see declaration of 'timespec'
make[3]: *** [fdmgr.obj] Error 2
make[3]: Leaving directory `c:/epics/base-3.15.2/src/libCom/O.win32-x86'
make[2]: *** [install.win32-x86] Error 2
make[2]: Leaving directory `c:/epics/base-3.15.2/src/libCom'
make[1]: *** [libCom.install] Error 2
make[1]: Leaving directory `c:/epics/base-3.15.2/src'
make: *** [src.install] Error 2
make: Leaving directory `c:/epics/base-3.15.2'


Sent from
Mail for Windows 10







------------------------------

_______________________________________________
Tech-talk mailing list Tech-talk@aps.anl.gov
https://mailman.aps.anl.gov/mailman/listinfo/tech-talk


End of Tech-talk Digest, Vol 9, Issue 263
*****************************************