EPICS Home

Experimental Physics and Industrial Control System


 
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  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 
<== Date ==> <== Thread ==>
Subject: Re: Modbus Binary Output Readbacks
From: "Wallace, Alex" <[email protected]>
To: Mark Rivers <[email protected]>, Mark Engbretson <[email protected]>
Cc: "[email protected]" <[email protected]>
Date: Fri, 16 Oct 2015 00:19:48 +0000 
For example, I use an output coil as the epics request to open a valve. That coil is AND'd with a permissive bit and the result is the state of the valve solenoid control line. If the interlock is not satisfied, the EPICS bit is written false by the PLC, so when the interlock is recovered the valve doesn't automatically open.

As for the loop, the first step in the Koyo PLCs is to process the modbus state changes and apply them to the PLC memory (please correct me if I misunderstood this). Then it reads the PLC inputs, processes the logic, then writes the outputs, and finally modbus. If the EPICS state change on a modbus coil comes in at the middle of that cycle, then modbus will update the record with the value that the PLC had (I might not understand this step correctly). On the next PLC cycle the PLC gets the coil change from modbus, and maybe it passes through the logic. This value is now written into the record, and so on. Seems like it might loop for a bit... maybe or maybe I am overthinking this.

-Alex
________________________________________
From: Mark Rivers <[email protected]>
Sent: Thursday, October 15, 2015 11:28 AM
To: Wallace, Alex; Mark Engbretson
Cc: [email protected]
Subject: RE: Modbus Binary Output Readbacks

Hi Alex,

What causes those output coils to change besides EPICS writes?

> Will that construct cause a loop if the PLC is finishing a cycle?

I don't understand the question.   What do you mean by finishing a cycle?  This may go back to my first question, is the PLC also writing to the same coil that EPICS writes to?

Mark



-----Original Message-----
From: Wallace, Alex [mailto:[email protected]]
Sent: Thursday, October 15, 2015 1:24 PM
To: Mark Rivers; Mark Engbretson
Cc: [email protected]
Subject: Re: Modbus Binary Output Readbacks

I am using a Beckhoff PLC which has register/coil areas where only certain modbus operations are permitted. These are soft IO in the sense that you choose what these coils and registers are linked to in your PLC program. So I use the output coils as the EPICS control coils. Similar to the C memory area in the Koyo PLCs.

Mark E. I do want one record to do it all. However, Mark R.'s construct should be good enough for farm use, especially if I use it as a template. Seems like it could be built into a bo record for the modbus module?

Will that construct cause a loop if the PLC is finishing a cycle?

-Alex

________________________________________
From: Mark Rivers <[email protected]>
Sent: Wednesday, October 14, 2015 8:05 PM
To: Mark Engbretson
Cc: Wallace, Alex; [email protected]
Subject: RE: Modbus Binary Output Readbacks

> I read this as a request for the modbus record to internally do this, so that you don't have to set up one block of
> registers to read, and then a different set with a different name to write.  No?

That is not possible with the current architecture, but it could be considered for the future.  Currently the modbus asyn port drivers are write-only or read-only.  The write-only drivers do have the option to do a single read operation at initialization so the output records get set to the current hardware value (bumpless reboot).  We could change the architecture so there is an option for a driver that does both writes and reads.  In that case because it is the same asyn port driver, a new feature I added to asyn device support in R4-26 could be used.  Output records that have the info tag

info(asyn:READBACK, "1")

will update their value when a callback with occurs.  This would solve Alex's problem without extra database records.

I question how common the need to update a coil value via a readback is.  What is causing the coil value to change asynchronously from the output record?  If this is a PLC then certainly the PLC can change a coil value.  But if the PLC is controlling a coil then I would not think it a good idea to have EPICS also controlling it.

Alex, can you explain your use case?

Mark
________________________________________
From: Mark Engbretson [[email protected]]
Sent: Wednesday, October 14, 2015 9:29 PM
To: Mark Rivers
Cc: Wallace, Alex; [email protected]
Subject: Re: Modbus Binary Output Readbacks

I read this as a request for the modbus record to internally do this, so that you don't have to set up one block of registers to read, and then a different set with a different name to write.  No?


On Oct 14, 2015, at 21:21, Mark Rivers <[email protected]> wrote:

Hi Alex,

You can definitely have 2 two modbus ports pointing at the same registers, one for read and write.

One way to keep your bo record in sync with the coil is to use the following database construct.

record(bo, "$(P)$(R)B0")
{
   field(OUT, "$(P)$(R)BO_write PP")
}

record(bo, "$(P)$(R)B0_write")
{
   field(SDIS, "$(P)$(R)B0_Sync.PACT")
   field(DISV, "1")
   field(DTYP, "asynInt32")
   field(OUT, "@asyn($(OUTPORT),$(ADDR),$(TIMEOUT))")
}

record(bi, "$(P)$(R)BI")
   field(DTYP, "asynInt32")
   field(INP,  "@asyn($(INPORT),$(ADDR),$(TIMEOUT))")
   field(SCAN, "I/O Intr")
   field(FLNK, "$(P)$(R)B0_Sync")
}

record(bo, "$(P)$(R)BO_Sync")
{
   field(DOL,  "$(P)$(R)BI NPP")
   field(OMSL, "closed_loop")
   field(OUT,  "$(P)$(R)BO PP")
}

The BO record is the record your application writes to.  It uses soft device support.  It sends its output to the BO_write record that actually does the modbus write.  That record is disabled if it is being processed as a result of a callback to the bi record.  The BI record is I/O Intr processed when the coil value changes.  It writes the value to the BO record via the BO_sync record.  Note that I took this example from a non-modbus application so the DTYP and asyn link syntax is probably wrong, but you get the idea.

Mark




________________________________
From: [email protected] [[email protected]] on behalf of Wallace, Alex [[email protected]]
Sent: Wednesday, October 14, 2015 8:51 PM
To: [email protected]
Subject: Modbus Binary Output Readbacks


Hi,


Can anyone see an issue with modifying the modbus module to give certain records, eg. binary output (bo), two modbus ports to use, one for writes and one to keep the record syncd with the PLC output coil state?


There should be no reason I can see for having two modbus ports pointing at the same registers, one for read and write. But as for the bo record, I'm not really sure where to begin.


Thanks!

-Alex
References:
Modbus Binary Output Readbacks Wallace, Alex
RE: Modbus Binary Output Readbacks Mark Rivers
Re: Modbus Binary Output Readbacks Mark Engbretson
RE: Modbus Binary Output Readbacks Mark Rivers
Re: Modbus Binary Output Readbacks Wallace, Alex
RE: Modbus Binary Output Readbacks Mark Rivers
Navigate by Date:
Prev: Re: VxWorks IOC machine check exception Ron Sluiter
Next: Re: CSS, issue with PVUtil.writePV timeout David Michel
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: Modbus Binary Output Readbacks Mark Rivers
Next: VxWorks IOC machine check exception J. Lewis Muir
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