M
Jiri Baum wrote:
>
> Hello,
>
> (I'm answering to the two issues separately)
>
> Mario de Sousa:
> > Issue 2
> > -------
>
> > For logic type modules, these will have many scratch variables that maybe
> > don't need to be interfaced to any other module. This raises the
> > 'philosophical' question of whether these variables should be mapped onto
> > linuxplc points.
>
> > Take the iec compiler for example. We can take the route of (a) having
> > every Mx.y 'variable' be a linuxplc point, which means they all have to
> > be configured, or (b) we can choose to assume that this memory is private
> > to the iec logic module, and only explicitly configured memory locations
> > would be mapped onto linuxplc points.
>
> I'm for option (a), on the grounds that even private variables should be
> visible to the debugging/tracing/etc tools.
Yes, I agree, but notice that these variables would only be visible once the module calls plc_update(). Won't this be too carse for some
debugging sessions?
> Otherwise there'll either have
> to be a separate debugging/tracing tool for every kind of logic module, or
> the option of putting them in the globalmap anyway. (...)
>
> I'm not sure to what extent this actually matters to the smm/gmm. It should
> be able to handle things anyway (for inter-module communication), and once
> it can, there's not much reason why it shouldn't.
Yes, it can handle both situations, but I think it needs to be optimised for either one. Currently each named linuxplc point takes up
48+36 bytes of configuration memory, and 1 to 32 _bits_ of user memory. This ratio is much too big if we are going to have every scratch variable as a named linuxplc point. Imagine needing 100K of
configuration memory just so we can have 1K of real memory!
Maybe we need to come back and consider arrays or structures of linuxplc points?
I don't know. I haven't really thought this through yet. I'm still considering the implications...
Mario.
----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
>
> Hello,
>
> (I'm answering to the two issues separately)
>
> Mario de Sousa:
> > Issue 2
> > -------
>
> > For logic type modules, these will have many scratch variables that maybe
> > don't need to be interfaced to any other module. This raises the
> > 'philosophical' question of whether these variables should be mapped onto
> > linuxplc points.
>
> > Take the iec compiler for example. We can take the route of (a) having
> > every Mx.y 'variable' be a linuxplc point, which means they all have to
> > be configured, or (b) we can choose to assume that this memory is private
> > to the iec logic module, and only explicitly configured memory locations
> > would be mapped onto linuxplc points.
>
> I'm for option (a), on the grounds that even private variables should be
> visible to the debugging/tracing/etc tools.
Yes, I agree, but notice that these variables would only be visible once the module calls plc_update(). Won't this be too carse for some
debugging sessions?
> Otherwise there'll either have
> to be a separate debugging/tracing tool for every kind of logic module, or
> the option of putting them in the globalmap anyway. (...)
>
> I'm not sure to what extent this actually matters to the smm/gmm. It should
> be able to handle things anyway (for inter-module communication), and once
> it can, there's not much reason why it shouldn't.
Yes, it can handle both situations, but I think it needs to be optimised for either one. Currently each named linuxplc point takes up
48+36 bytes of configuration memory, and 1 to 32 _bits_ of user memory. This ratio is much too big if we are going to have every scratch variable as a named linuxplc point. Imagine needing 100K of
configuration memory just so we can have 1K of real memory!
Maybe we need to come back and consider arrays or structures of linuxplc points?
I don't know. I haven't really thought this through yet. I'm still considering the implications...
Mario.
----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc