point.bit syntax now available

J

Thread Starter

Jiri Baum

Hello, I've just added few lines of code to the lPLC library so that if you have a multi-bit point "foo", you can call plc_pt_by_name("foo.3") and it'll return the right thing. Bits are numbered from 0 to 31 in decimal. It's an error if foo isn't big enough. (Exception: if foo is 0-bit, a 0-bit point is returned.) The user can override this by explicitly defining a point called "bit.3". I hope no-one's offended by my choice of syntax; I know this was requested for the IEC compiler, and maybe a some others as well - doing it in the gmm means that it works for any module - even, say, I/O (so you can define an 8-bit integer point and map the individual bits to the individual inputs). Jiri -- Jiri Baum <[email protected]> Q: Why did the chicken cross the Moebius Strip? A: To get to the other... um... er... --r.h.f.r _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
M

Mario de Sousa

I'm sorry Jiri, but I don't quite agree with you here, and I think this should be removed. We already have the: /* * Create a sub_point handle. * * This functions creates a handle to an anonymous point corresponding to * 'length' bits of point 'parent_pt', starting from 'bit' of that * 'parent_pt' * * If the point doesn't exist, the `valid' field of the result will be 0. */ plc_pt_t plc_subpt(plc_pt_t parent_pt, u8 bit, u8 length); which I think should be used instead. It has the advantage that we are not gobling up the plc point name namespace for the LinuxPLC's purpose. I think your choice of syntax is a potential source of great confusion. Please feel free to disagree, and defend your position. As always, I am open to being convinced otherwise. Cheers, Mario. ---------------------------------------------------------------------------- Mario J. R. de Sousa [email protected] ---------------------------------------------------------------------------- The box said it requires Windows 95 or better, so I installed Linux _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
> Jiri Baum wrote: > > I've just added few lines of code to the lPLC library so that if you > > have a multi-bit point "foo", you can call plc_pt_by_name("foo.3") Mario de Sousa: > I'm sorry Jiri, but I don't quite agree with you here, and I think this > should be removed. > We already have the: > * Create a sub_point handle. Yes, that's what it's using. The advantage of this over the plc_subpt() function is that it's available to the user, regardless of whether the module is written to do it. > It has the advantage that we are not gobling up the plc point name > namespace for the LinuxPLC's purpose. I think your choice of syntax is a > potential source of great confusion. Note that this is effectively an error-recovery routine: it only comes into play once the library hasn't found the point you are looking for. As long as you define all the points you use, you'll never see the feature. There *is* some potential for confusion; but mostly I think the result will be that the library simply does what you would expect. The confusion can only come in once you've made a mistake; then again, that's when confusion usually strikes. Perhaps it should log a warning message: "didn't find point `foo.3', assuming you meant bit 3 of `foo'". > Please feel free to disagree, and defend your position. As always, I am > open to being convinced otherwise. I don't mind leaving it out, or giving it a different name, if the consensus is that it breaks things... Jiri -- Jiri Baum <[email protected]> Q: Why did the chicken cross the Moebius Strip? A: To get to the other... um... er... --r.h.f.r _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
M

Mario de Sousa

Jiri Baum wrote: > > > Jiri Baum wrote: > > > I've just added few lines of code to the lPLC library so that if you > > > have a multi-bit point "foo", you can call plc_pt_by_name("foo.3") > > Mario de Sousa: > > I'm sorry Jiri, but I don't quite agree with you here, and I think this > > should be removed. > > > We already have the: > > * Create a sub_point handle. > > Yes, that's what it's using. > > The advantage of this over the plc_subpt() function is that it's available > to the user, regardless of whether the module is written to do it. Right. I understand your logic now. But there is an alternative for this too. The user can create an alias! # the POINT_ALIAS table # --------------------- # syntax: # point_alias name "full name" org_name [bit [length]] # # where: # point_alias = 'point_alias' identifier # name = Name used to search for point in plc_pt_by_name() # full name = More extensive description of the point # This information is not loaded into the confmap of the plc # bit = The first bit, of the original point, that this alias will # reference. This is optional, defaulting to 0. # length = the size in bits of the point. The point must not overflow # outside the original point (i.e. (bit + length) < # (length of org_name point). The length is optional, defaulting # to the length of the org_name point if the bit is explicitly # specified, and 1 otherwise. # # note: # (1) offset, bit and length may be written in hexadecimal (0xF45A), # octal (0172132) or decimal (62554) formats. # Granted. This will take up more configuration memory than your alternative, but I still prefer the pt_alias version for now. What do you think? Mario. -- ---------------------------------------------------------------------------- Mario J. R. de Sousa [email protected] ---------------------------------------------------------------------------- The box said it requires Windows 95 or better, so I installed Linux _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
Jiri Baum: > > The advantage of this over the plc_subpt() function is that it's available > > to the user, regardless of whether the module is written to do it. Mario de Sousa: > Right. I understand your logic now. > But there is an alternative for this too. > The user can create an alias! Ah, I'd half-forgotten about those. > Granted. This will take up more configuration memory than your > alternative, but I still prefer the pt_alias version for now. > What do you think? Make it an option? Something like "auto_bit_aliases" or "magic_bit_aliases"... (The C version would have the plc_ prefix.) Jiri, I'm thinking magic_bit_aliases, but maybe I've read too much fantasy -- Jiri Baum <[email protected]> Q: Why did the chicken cross the Moebius Strip? A: To get to the other... um... er... --r.h.f.r _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
M

Mario de Sousa

Yes. I was away from my terminal for an hour and started to have a change of heart. An option in linuxplc.conf that can turn this on and off is the best solution. Either option name will do. Your choice... Cheers, Mario. ---------------------------------------------------------------------------- Mario J. R. de Sousa [email protected] ---------------------------------------------------------------------------- The box said it requires Windows 95 or better, so I installed Linux _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
Curt Wuollet: > For what it's worth, I like to be able to do one bit per digital point > for efficiency's sake on very small machines. No problem, this is just an additional thing. If it can't find the point you asked for, it checks to see if you may have meant it as a point.bit thing. So if you ask for "foo.3" it'll look: - first for the point called "foo.3", and return a handle to it; - if it doesn't find it, it'll look for a point called "foo", at least 4 bits wide, and return a handle to bit 3 of "foo". Jiri -- Jiri Baum <[email protected]> Q: Why did the chicken cross the Moebius Strip? A: To get to the other... um... er... --r.h.f.r _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
Jiri Baum: > > Make it an option? > > Something like "auto_bit_aliases" or "magic_bit_aliases"... (The C > > version would have the plc_ prefix.) > > I'm thinking magic_bit_aliases, but maybe I've read too much fantasy Mario de Sousa: > Yes. I was away from my terminal for an hour and started to have a change > of heart. An option in linuxplc.conf that can turn this on and off is the > best solution. OK. > Either option name will do. Your choice... I'll go for magic_bit_aliases Jiri -- Jiri Baum <[email protected]> Q: Why did the chicken cross the Moebius Strip? A: To get to the other... um... er... --r.h.f.r _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
I wrote (about the plc_pt_by_name() function): > If it can't find the point you asked for, it checks to see if you may > have meant it as a point.bit thing. > So if you ask for "foo.3" it'll look: > - first for the point called "foo.3", and return a handle to it; > - if it doesn't find it, it'll look for a point called "foo", at > least 4 bits wide, and return a handle to bit 3 of "foo". This second part is now optional, and normally defaults to *off*. It can be turned on or off: - a module can change the default by setting plc_magic_bit_aliases to 1 before calling plc_init() - for instance if it's a language interpreter and the language specifies the .bit syntax. - PLC-wide setting magic_bit_aliases in section PLC (1=on, 0=off) - module-specific setting magic_bit_aliases in module's section, overriding the PLC-wide setting - a module can also set plc_magic_bit_aliases to 0 or 1 after init to override the user setting. This is discouraged. Jiri -- Jiri Baum <[email protected]> Q: Why did the chicken cross the Moebius Strip? A: To get to the other... um... er... --r.h.f.r _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
Top