Re: Extending Configuration to include Connection String
Hi Ben, In your case, it seems like a good idea to keep them in the Configuration. Jinlin Ben Hutcheson 於 2023年1月7日 週六 下午5:37寫道： > Hi Jinlin, > > Yeah we do parse the string and get those values, however currently we > don't save them in the configuration for later use. > > Although I have been playing around this morning with getting the values > from the netty channel that is created. I might just use this instead. > > thanks > > Ben > > On Sat, Jan 7, 2023 at 10:28 AM jl hong wrote: > > > Hi Ben, > > > > I see we parse the connection string as a URL, and it contains IP, port, > > and protocol. Did you mean we needn’t parse it again? > > > > Jinlin > > > > Ben Hutcheson 於 2023年1月7日 週六 下午3:05寫道： > > > > > Hi, > > > > > > There's been a few times where I have had to pass the connection string > > > information through to the driver logic to be used in the connection > > phase. > > > For OPC-UA it's passed as a string through to the OPCUA device to help > > > select the correct endpoint. As well as now in the Profinet driver as > we > > > need to create multiple sockets and use multiple protocols to create > the > > > connection, some of which we need to know what interface we would like > to > > > listen on. > > > > > > I propose to extend the Configuration interface to include the > connection > > > string information such as the ip address, port and transport. This way > > I'm > > > not recreating the getConnection logic for each driver. > > > > > > What are peoples thoughts? > > > > > > Ben > > > > > >
Re: Extending Configuration to include Connection String
Hi Ben, I see we parse the connection string as a URL, and it contains IP, port, and protocol. Did you mean we needn’t parse it again? Jinlin Ben Hutcheson 於 2023年1月7日 週六 下午3:05寫道： > Hi, > > There's been a few times where I have had to pass the connection string > information through to the driver logic to be used in the connection phase. > For OPC-UA it's passed as a string through to the OPCUA device to help > select the correct endpoint. As well as now in the Profinet driver as we > need to create multiple sockets and use multiple protocols to create the > connection, some of which we need to know what interface we would like to > listen on. > > I propose to extend the Configuration interface to include the connection > string information such as the ip address, port and transport. This way I'm > not recreating the getConnection logic for each driver. > > What are peoples thoughts? > > Ben >
Re: [DISCUSS] Having a in-person community meetup?
Hi Chris, It’s so appreciated for your invitation. Of course, I like to attend the event, but it is unrealistic for me, because of many limitations such as money, free time, and the abroad experience, I haven't even ever left China before. I like to dream I can see all of you one day, if I have a Gulfstream G650 I like to take all of you travelling all over the world, Haha. Jinlin Christofer Dutz 於 2023年1月5日 週四 下午6:59寫道： > Hi Jinlin, > > Would you be willing and able to attend such an event? > You would be more than welcome. > > As I’m also part of the Apache Travel Assistance committee … I’d also like > to ask any others here too: > Would you like to attend such an event, but the costs of travelling are > what you can’t afford or would have a too big impact on your budget to be > willing to come? > > Because there theoretically is the option of having Apache cover the costs > for travelling and accommodation. However, this would put quite a lot of > extra work for us for setting it up and running it. > So, if it’s only 1-2 people, this probably doesn’t make much sense, but if > there were more, it might make sense. > > And please … don’t say: “I can’t afford it and would like assistance”, if > the problem is that the fuel has become too expensive for your Ferrari or > the parking costs for your private jet are skyrocketing ;-) > > And if you don’t want to publicly answer … feel free to DM me. > > Chris > > > From: jl hong > Date: Thursday, 5. January 2023 at 02:16 > To: dev@plc4x.apache.org > Subject: Re: [DISCUSS] Having a in-person community meetup? > This sounds exciting :) > > Jinlin > > Lukas Ott 於 2023年1月5日 週四 上午12:11寫道： > > > cool :-) would be fun so that I can finally ask all my questions in > person > > ;-) > > > > Am Mi., 4. Jan. 2023 um 16:37 Uhr schrieb Ben Hutcheson < > > ben.hut...@gmail.com>: > > > > > Sounds like fun. > > > > > > Ben > > > > > > On Wed, Jan 4, 2023 at 4:30 PM Christofer Dutz < > > christofer.d...@c-ware.de> > > > wrote: > > > > > > > Ok … > > > > > > > > Uwe from codecentric FFM (the new office) was delighted my me asking > if > > > > codecentric would be willing to accommodate us during the hackathon. > > > > So, that would be one option … I guess Sebastian would like that > option > > > ;-) > > > > > > > > Chris > > > > > > > > > > > > From: Christofer Dutz > > > > Date: Wednesday, 4. January 2023 at 16:24 > > > > To: dev@plc4x.apache.org > > > > Subject: [DISCUSS] Having a in-person community meetup? > > > > Hi all, > > > > > > > > some of you remember the times around our graduation. We had loads of > > > > in-presence meetups and that really fuled the drive in the community. > > > > Covid sort of was the opposite and it felt like we were sort of > losing > > > our > > > > drive a bit. > > > > > > > > Now that Ben now also lives in Germany, I wanted to bring up this > topic > > > > again. > > > > > > > > What do you folks think of a 2-3-day hackathon on PLC4X (and possibly > > the > > > > Historian)? > > > > Probably we would need to sort of do it Friday to Sunday. > > > > > > > > Also currently probing if we could not get TAC to help finance the > > > travels > > > > of everyone except me. > > > > > > > > Even if I would love a week on the Bahamas, probably something in > > Germany > > > > somewhere round Frankfurt or Stuttgart would make sense > > > > (from the perspective of people being able to come there via public > > > > transport and keeping the connection options simple and cheaper) > > > > > > > > What do you folks think. > > > > > > > > > > > > Chris > > > > > > > > > >
Re: [DISCUSS] Having a in-person community meetup?
This sounds exciting :) Jinlin Lukas Ott 於 2023年1月5日 週四 上午12:11寫道： > cool :-) would be fun so that I can finally ask all my questions in person > ;-) > > Am Mi., 4. Jan. 2023 um 16:37 Uhr schrieb Ben Hutcheson < > ben.hut...@gmail.com>: > > > Sounds like fun. > > > > Ben > > > > On Wed, Jan 4, 2023 at 4:30 PM Christofer Dutz < > christofer.d...@c-ware.de> > > wrote: > > > > > Ok … > > > > > > Uwe from codecentric FFM (the new office) was delighted my me asking if > > > codecentric would be willing to accommodate us during the hackathon. > > > So, that would be one option … I guess Sebastian would like that option > > ;-) > > > > > > Chris > > > > > > > > > From: Christofer Dutz > > > Date: Wednesday, 4. January 2023 at 16:24 > > > To: dev@plc4x.apache.org > > > Subject: [DISCUSS] Having a in-person community meetup? > > > Hi all, > > > > > > some of you remember the times around our graduation. We had loads of > > > in-presence meetups and that really fuled the drive in the community. > > > Covid sort of was the opposite and it felt like we were sort of losing > > our > > > drive a bit. > > > > > > Now that Ben now also lives in Germany, I wanted to bring up this topic > > > again. > > > > > > What do you folks think of a 2-3-day hackathon on PLC4X (and possibly > the > > > Historian)? > > > Probably we would need to sort of do it Friday to Sunday. > > > > > > Also currently probing if we could not get TAC to help finance the > > travels > > > of everyone except me. > > > > > > Even if I would love a week on the Bahamas, probably something in > Germany > > > somewhere round Frankfurt or Stuttgart would make sense > > > (from the perspective of people being able to come there via public > > > transport and keeping the connection options simple and cheaper) > > > > > > What do you folks think. > > > > > > > > > Chris > > > > > >
Re: [DISCUSS] Rename Fields -> Tags?
Hello Chris, I had the same confusion with Łukasz about what "Tag" meant when I first met it in using Rockwell PLCs.Maybe it is more difficult to understand than "Field".Also, I think "Field" is not accurate enough too. Finally, I think either "Tag" or "Field" is acceptable, and people should both be able to understand it from the document or context. By the way, we call it "Point Position" in Chinese, I translated directly. Christofer Dutz 於 2022年11月8日 週二 凌晨4:49寫道： > Probably should rename „fieldQuery“ to „fieldAddress” (or tagAddress) as I > split Fields and Queries as a query usually targets more than one element > and an address normaly doesn’t. > > Chris > > From: Christofer Dutz > Date: Monday, 7. November 2022 at 21:40 > To: dev@plc4x.apache.org > Subject: Re: [DISCUSS] Rename Fields -> Tags? > And regarding your points, Lukasz, > > The output from the Browse API is that it is a BrowseItem. This contains a > Field (or Tag if we rename it) and loads of metadata. > Is the Field readable, writable, subscribable, loads of protocol dependent > options. > > The Field itself now should be able to produce an address string that > should be able to re-produce it. The APIs all support “addFieldQuery” which > takes this string representation or “addField” which directly receives the > field object. > > Chris > > > From: Łukasz Dywicki > Date: Monday, 7. November 2022 at 13:48 > To: dev@plc4x.apache.org > Subject: Re: [DISCUSS] Rename Fields -> Tags? > Hey Chris, > I do not insist on any side. Knowing how hard it is to get a "common > understanding" on certain things I think it is easier if we stick with > project specific concept. > > Other point, we do not need to re-use a PlcField and field notion > everywhere. For example output from browse api might be a descriptor > which can be used to construct a field address. After all, a browsing > functionality might provide more information than needed to fetch data - > ie. human readable name, description or other elements which are > irrelevant for driver to get data. > > As a side note, I do acknowledge that best time to do naming and larger > API alignments is prior 1.x release. > > Best, > Łukasz > > On 6.11.2022 13:32, Christofer Dutz wrote: > > Hi Lukasz, > > > > even in protocols like ADS and EIP at Rivian everyone is referring to > any data point as a “Tag”. > > So far, I haven’t come across a single person saying something else on > LinkedIn. > > https://www.linkedin.com/feed/update/urn:li:activity:6994584721582088192 > > > > And keep in mind: PLC4X is meant to be the bridge between IT and OT, and > we chose a lot of stuff (Like the address patterns, etc.) to match the OT > expectations. After all, I will most probably be an IT person asking the OT > person: Please give me the address for Field/Tag XYZ. So, I think naming it > “Tag” would be better. > > > > I would like to name it to match the most used term: I know that this > isn’t always a perfect match in all protocols, but I guess that’s the > difference between providing a “shared API” or building individual drivers > for each protocol. > > > > And currently we name it “Query” in Go … so you currently say: > “AddQuery” instead of “AddField”. > > > > Chris > > > > > > From: Łukasz Dywicki > > Date: Sunday, 6. November 2022 at 11:45 > > To: dev@plc4x.apache.org , Christofer Dutz < > christofer.d...@c-ware.de> > > Subject: Re: [DISCUSS] Rename Fields -> Tags? > > Hey Chris, > > I am not certain if "tag" is standardized or not. Earlier, knowing only > > modbus registers and bacnet objects, I been confused multiple times what > > the tag is. For regular IT tag is rather a marker placed on something to > > categorize elements. Our field currently specifies rather a unique data > > point than a tag. > > If tag meaning comes from IEC standard then I'd opt in for a change. If > > its not standardized then I'd advice staying with a field. Our use is > > mixed IT/OT (with probably still more IT?), if we stick too much to > > automation industry terminology then we will need to bake definition of > > a tag, fight situations where we miss a "common understanding" cause we > > can't beg others for unification of their meaning. > > > > I've seen tag used in context of ethernet/ip (more precisely Rockwell > > PLCs), but haven't done a research of why. Keep in mind we have also > > object oriented protocols such as BACnet (with `device.object.property`) > > and CANopen (with `device.sdo` or `device.tpdo..`) thus in their context > > tag is far less meaningful than field. > > > > Cheers, > > Łukasz > > > > On 5.11.2022 12:23, Christofer Dutz wrote: > >> Hi all, > >> > >> I’m currently working on harmonizing our different API variants a bit > and hopefully finalizing our Browse API (Which sort of wen’t through > multiple levels of change between Java and Go, back to Java and now back to > Go. > >> > >> One thing I learned at Rivian is, that everyone seems to be talking > about “Tags” on PLCs. So I asked on
Re: [DISCUSS] Enable GitHub issues?
ok :) Lukas Ott 于2022年11月4日 周五20:08写道： > Feel free to add them as labels on our Github :-) > > Am Fr., 4. Nov. 2022 um 10:56 Uhr schrieb jl hong >: > > > Hello Lukas, > > > >- Driver-Profinet > >- Driver-ADS > >- API > >- Driver-S7 > >- Core > >- Util-Pool > >- newbie > >- Code-Generation > >- Driver-Modbus > >- Integration-NiFi > >- feature-request > >- Driver-OPC-UA > >- documentation > >- Scraper > >- Driver-Fatek > >- Testing > >- Integration-Camel > >- Driver-Ethernet/IP > >- beginner > >- feature > >- low-hanging-fruit > >- easy-fix > >- PLC4C > >- documentation-update > >- docker > >- Integration-Kafka-Connect > >- examples > >- Build > >- Driver-CANopen > >- PLC4J > > > > The list which I got by jira-to-issues is current labels in our Jira. > > Some of them are not on your list, such as "driver". > > > > Lukas Ott 於 2022年11月1日 週二 凌晨3:25寫道： > > > > > I started cleaning up the Issues on JIRA. > > > Current status is 84 Issues. > > > > > > On Github I added a few labels. > > > Current list of labels (17): > > > > > >- test > > >- task > > >- wish > > >- new feature > > >- bug > > >- dependencies > > >- duplicate > > >- enhancement > > >- go > > >- good first issue > > >- help wanted > > >- invalid > > >- java > > >- python > > >- question > > >- wontfix > > >- github_actions > > > > > > Open tasks: > > > - Turn off new Jiras > > > This can be done by turning off the create issue permission for all > > > non-admins and adding an announcement in Portal Settings redirecting > > people > > > to GitHub. > > > - Migrating Existing Issues > > > - Create / Add Issue Template > > > > > > Am Mo., 31. Okt. 2022 um 19:26 Uhr schrieb Ben Hutcheson < > > > ben.hut...@gmail.com>: > > > > > > > +1 > > > > > > > > This will make the issues more visible, which is probably a good > thing. > > > > > > > > On Mon, 31 Oct 2022 at 12:06 pm, Lukas Ott > > > wrote: > > > > > > > > > Thank you Dominik! This > > > > > > > > > > It seems we have less of the Cons they are mentioning :-) > > > > > -> Google Summer of Code was not yet part of PLC4X > > > > > -> We only need to migrate around 100 Jira issues > > > > > -> I am not aware of any Milestones in our project that we track in > > > Jira. > > > > > > > > > > Concerning preparation: > > > > > - We already have list of labels > > > > > List to be added: > > > > > > > > > > Category > > > > > > > > > > Values > > > > > > > > > > Priority > > > > > > > > > > "P0", "P1", "P2", "P3" > > > > > > > > > > Type > > > > > > > > > > "Bug", "Improvement", "New Feature", "Task", "Test", "Wish", > "Outage" > > > > > > > > > > Component > > > > > > > > > > One label per JIRA component, formatted "Component: component>" > > > > (e.g. > > > > > "Component: sdk-go") > > > > > > > > > > Status > > > > > > > > > > "Awaiting Triage", "Fixed", "Not a problem", "Duplicate" > > > > > > > > > > > > > > > - Yes we should add a issue template > > > > > This can be done by turning off the create issue permission for all > > > > > non-admins and adding an announcement in Portal Settings > redirecting > > > > people > > > > > to GitHub. > > > > > - Update documentation after migration > > > > > > > > > > Next steps > > > > > - Turn on Github Issues Tab > > > > > - Turn off Jira Tickets (How do we do that?) > > > >
Re: [DISCUSS] Enable GitHub issues?
Hello Lukas, - Driver-Profinet - Driver-ADS - API - Driver-S7 - Core - Util-Pool - newbie - Code-Generation - Driver-Modbus - Integration-NiFi - feature-request - Driver-OPC-UA - documentation - Scraper - Driver-Fatek - Testing - Integration-Camel - Driver-Ethernet/IP - beginner - feature - low-hanging-fruit - easy-fix - PLC4C - documentation-update - docker - Integration-Kafka-Connect - examples - Build - Driver-CANopen - PLC4J The list which I got by jira-to-issues is current labels in our Jira. Some of them are not on your list, such as "driver". Lukas Ott 於 2022年11月1日 週二 凌晨3:25寫道： > I started cleaning up the Issues on JIRA. > Current status is 84 Issues. > > On Github I added a few labels. > Current list of labels (17): > >- test >- task >- wish >- new feature >- bug >- dependencies >- duplicate >- enhancement >- go >- good first issue >- help wanted >- invalid >- java >- python >- question >- wontfix >- github_actions > > Open tasks: > - Turn off new Jiras > This can be done by turning off the create issue permission for all > non-admins and adding an announcement in Portal Settings redirecting people > to GitHub. > - Migrating Existing Issues > - Create / Add Issue Template > > Am Mo., 31. Okt. 2022 um 19:26 Uhr schrieb Ben Hutcheson < > ben.hut...@gmail.com>: > > > +1 > > > > This will make the issues more visible, which is probably a good thing. > > > > On Mon, 31 Oct 2022 at 12:06 pm, Lukas Ott > wrote: > > > > > Thank you Dominik! This > > > > > > It seems we have less of the Cons they are mentioning :-) > > > -> Google Summer of Code was not yet part of PLC4X > > > -> We only need to migrate around 100 Jira issues > > > -> I am not aware of any Milestones in our project that we track in > Jira. > > > > > > Concerning preparation: > > > - We already have list of labels > > > List to be added: > > > > > > Category > > > > > > Values > > > > > > Priority > > > > > > "P0", "P1", "P2", "P3" > > > > > > Type > > > > > > "Bug", "Improvement", "New Feature", "Task", "Test", "Wish", "Outage" > > > > > > Component > > > > > > One label per JIRA component, formatted "Component: " > > (e.g. > > > "Component: sdk-go") > > > > > > Status > > > > > > "Awaiting Triage", "Fixed", "Not a problem", "Duplicate" > > > > > > > > > - Yes we should add a issue template > > > This can be done by turning off the create issue permission for all > > > non-admins and adding an announcement in Portal Settings redirecting > > people > > > to GitHub. > > > - Update documentation after migration > > > > > > Next steps > > > - Turn on Github Issues Tab > > > - Turn off Jira Tickets (How do we do that?) > > > > > > > > > > > > > > > Am Mo., 31. Okt. 2022 um 18:48 Uhr schrieb Dominik Riemer < > rie...@fzi.de > > >: > > > > > > > I've recently looked at other ASF projects which discussed migration > > from > > > > Jira to Github, e.g., here are some discussions from Apache Beam: > > > > > > > > Feature Comparison: > > > > > > > > > > https://docs.google.com/document/d/1_n7gboVbSKPs-CVcHzADgg8qpNL9igiHqUPCmiOslf0/edit#heading=h.r8qwrrbs8odn > > > > Migration Plan: > > > > > > > > > > https://docs.google.com/document/d/1powrXGbjMLMYl9ibRzMda5o5HM_p44XvBy5MZu75Q5E/edit#heading=h.wskna8eurvjv > > > > > > > > And Beam also open-sourced the migration tool they used: > > > > https://github.com/google/jira-to-issues > > > > > > > > I've not yet tried it, but looks quite good > > > > > > > > Cheers > > > > Dominik > > > > > > > > > > > > -Original Message- > > > > From: Lukas Ott > > > > Sent: Monday, October 31, 2022 6:41 PM > > > > To: dev@plc4x.apache.org > > > > Subject: Re: [DISCUSS] Enable GitHub issues? > > > > > > > > I will look into that. > > > > > > > > Currently we have 103 open jira issues. Oldest one is more than 2 > years > > > > ago. > > > > > > > > > > > > > > > > Am Mo., 31. Okt. 2022 um 18:28 Uhr schrieb Christofer Dutz < > > > > christofer.d...@c-ware.de>: > > > > > > > > > I’m also fine with that. > > > > > So anyone willing to work on the migration? > > > > > > > > > > Chris > > > > > > > > > > From: Lukas Ott > > > > > Date: Monday, 31. October 2022 at 17:50 > > > > > To: dev@plc4x.apache.org > > > > > Subject: Re: [DISCUSS] Enable GitHub issues? > > > > > Hi Chris, > > > > > > > > > > In my humble opinion we should not run parallel. > > > > > > > > > > Our Jira has already a lot of issues that are outdated. > > > > > > > > > > So i opt for enabling GitHub Issues and migrating the few Jira > Issues > > > > > that are still worked on. > > > > > > > > > > This helps us also for cleaning up and having one public issue > > > > > tracker, where everyone can easily see what is worked on and what > is > > > > open. > > > > > > > > > > Luk > > > > > > > > > > Am Mo., 31. Okt. 2022 um 17:07 Uhr schrieb Christofer Dutz < > > > > >
Re: BOOLeans ;-)
Thank you, Chris :) Christofer Dutz 於 2022年11月1日 週二 凌晨12:09寫道： > I Ji, > > First of all: welcome to the team as our newest committer :-) > > I guess I really should start writing stuff like this up … then we can > discuss things here and once we’ve agreed on it, make sure we use the same > interpretation all over PLC4X. > > Chris > > From: jl hong > Date: Monday, 31. October 2022 at 02:25 > To: dev@plc4x.apache.org > Subject: Re: BOOLeans ;-) > Hello Chris, > Sorry for the late reply, but I've been a little busy lately. > By the way, I received an offer of to be a committer from PLC4X PCM(sent by > Hub) a few days ago, and I have already submitted the iCLA document, so I > would like to thank the PLC4X team for their trust in me. > To get back to the point, after your explanation I have a clearer > understanding of coil and register, I thought before that coil storage is > also continuous storage, so we read regitster's INT and read 16bit coil is > the same. > I agree with what you said that we should be writing up how we expect > different things to be read, and I will improve my code when we determine > how to do that. > > Christofer Dutz 於 2022年10月14日 週五 晚上9:34寫道： > > > Hi Ji, > > > > well … I know that you can theoretically interpret 8 digital inputs as a > > byte, but Coils in my understanding are usually directly mapped to > digital > > inputs on the Modbus device. So a COIL is technically just a bit … so > with > > “coil:1:BOOL[5], you’d be reading coil:1:BOOL, coil:2:BOOL, coil:3:BOOL, > > coil:4:BOOL, coil:5:BOOL. It would become “problematic if someone started > > reading coil:1:BOOL[5] and coil:3:BOOL[5] as he’d be reading stuff > double. > > Wasn’t objecting this, just wanted to point it out. > > > > I guess the reason your INT differs from BOOL-array is that you might be > > using a LittleEndian PLC and there two-byte values are read in a > different > > order. > > > > Does that help? > > > > I really think we should be writing up how we expect different things to > > be read and then to ensure all drivers follow that schema. > > > > Chris > > > > From: jl hong > > Date: Friday, 14. October 2022 at 00:55 > > To: dev@plc4x.apache.org > > Subject: Re: BOOLeans ;-) > > Hi, Chris. > > I'm sorry to interrupt your trip. > > 1. Regarding "a coil is a single-valued boolean .. Not sure what the > > offset means here?" issue, I just tried it and it works like any other > data > > type, but there are 2 small issues to deal with. > > (1) When we read the INT type, it returns a binary sort of "AB CD", while > > the BOOL type returns "BA DC", so we need to deal with the binary before > > reading the BOOL. > > (2) The Quantity needs to be added to Offset. > > > > 2. How to represent the offset and the number of arrays, I think it's > fine, > > as long as it's clearly described. > > > > Christofer Dutz 於 2022年10月13日 週四 晚上10:10寫道： > > > > > Well, I guess mostly I‘ve seen it more treated like: If there’s no “..” > > > the number is the size of the array, … if there’s a “..” then the > prefix > > is > > > the offset. And yes: the Golang approach is again very different to > what > > I > > > have seen be used in industrial automation. > > > > > > Chris > > > > > > From: Sebastian Rühl > > > Date: Thursday, 13. October 2022 at 09:06 > > > To: dev@plc4x.apache.org > > > Subject: Re: BOOLeans ;-) > > > In some language I saw that being used as ranges: > > > > > > BOOL[5] would be one bool at index 5 > > > BOOL[:5] would be 5 bools till index 5 > > > BOOL[3:5] would be 3 bools from index 3 to 5 > > > BOOL[2:] would be all bools from index 2 > > > BOOL[:-1] would be all bools till the last index -1 > > > > > > So maybe I'm wrong, but when you write 5.3:BOOL[5] you mean > > > 5.3:BOOL[:5], right? > > > > > > Sebastian > > > > > > On 2022/10/13 13:40:08 Christofer Dutz wrote: > > > > Hi all, > > > > > > > > seems we got a PR where someone implemented my proposal for handling > > > Booleans ( > > > > > > https://cwiki.apache.org/confluence/display/PLC4X/Cleanup+of+how+we+handle+all+the+bit-related+fields > > > ) > > > > For Modbus in Go (https://github.com/apache/plc4x/pull/545) > > > > > > > > I think we should probably finish some of the discussions on this and > > > document them in the project. > > > > > > > > With the latest discussions on the Browse API and how to deal with > > > (muti-dimensional) arrays … I think probably a notation: > > > > > > > > 5:BOOL[3..8] > > > > > > > > Would be better than: > > > > > > > > 5.3:BOOL[5] > > > > > > > > What do you think? > > > > > > > > Chris > > > > > > > > > >
Re: BOOLeans ;-)
Hello Chris, Sorry for the late reply, but I've been a little busy lately. By the way, I received an offer of to be a committer from PLC4X PCM(sent by Hub) a few days ago, and I have already submitted the iCLA document, so I would like to thank the PLC4X team for their trust in me. To get back to the point, after your explanation I have a clearer understanding of coil and register, I thought before that coil storage is also continuous storage, so we read regitster's INT and read 16bit coil is the same. I agree with what you said that we should be writing up how we expect different things to be read, and I will improve my code when we determine how to do that. Christofer Dutz 於 2022年10月14日 週五 晚上9:34寫道： > Hi Ji, > > well … I know that you can theoretically interpret 8 digital inputs as a > byte, but Coils in my understanding are usually directly mapped to digital > inputs on the Modbus device. So a COIL is technically just a bit … so with > “coil:1:BOOL[5], you’d be reading coil:1:BOOL, coil:2:BOOL, coil:3:BOOL, > coil:4:BOOL, coil:5:BOOL. It would become “problematic if someone started > reading coil:1:BOOL[5] and coil:3:BOOL[5] as he’d be reading stuff double. > Wasn’t objecting this, just wanted to point it out. > > I guess the reason your INT differs from BOOL-array is that you might be > using a LittleEndian PLC and there two-byte values are read in a different > order. > > Does that help? > > I really think we should be writing up how we expect different things to > be read and then to ensure all drivers follow that schema. > > Chris > > From: jl hong > Date: Friday, 14. October 2022 at 00:55 > To: dev@plc4x.apache.org > Subject: Re: BOOLeans ;-) > Hi, Chris. > I'm sorry to interrupt your trip. > 1. Regarding "a coil is a single-valued boolean .. Not sure what the > offset means here?" issue, I just tried it and it works like any other data > type, but there are 2 small issues to deal with. > (1) When we read the INT type, it returns a binary sort of "AB CD", while > the BOOL type returns "BA DC", so we need to deal with the binary before > reading the BOOL. > (2) The Quantity needs to be added to Offset. > > 2. How to represent the offset and the number of arrays, I think it's fine, > as long as it's clearly described. > > Christofer Dutz 於 2022年10月13日 週四 晚上10:10寫道： > > > Well, I guess mostly I‘ve seen it more treated like: If there’s no “..” > > the number is the size of the array, … if there’s a “..” then the prefix > is > > the offset. And yes: the Golang approach is again very different to what > I > > have seen be used in industrial automation. > > > > Chris > > > > From: Sebastian Rühl > > Date: Thursday, 13. October 2022 at 09:06 > > To: dev@plc4x.apache.org > > Subject: Re: BOOLeans ;-) > > In some language I saw that being used as ranges: > > > > BOOL[5] would be one bool at index 5 > > BOOL[:5] would be 5 bools till index 5 > > BOOL[3:5] would be 3 bools from index 3 to 5 > > BOOL[2:] would be all bools from index 2 > > BOOL[:-1] would be all bools till the last index -1 > > > > So maybe I'm wrong, but when you write 5.3:BOOL[5] you mean > > 5.3:BOOL[:5], right? > > > > Sebastian > > > > On 2022/10/13 13:40:08 Christofer Dutz wrote: > > > Hi all, > > > > > > seems we got a PR where someone implemented my proposal for handling > > Booleans ( > > > https://cwiki.apache.org/confluence/display/PLC4X/Cleanup+of+how+we+handle+all+the+bit-related+fields > > ) > > > For Modbus in Go (https://github.com/apache/plc4x/pull/545) > > > > > > I think we should probably finish some of the discussions on this and > > document them in the project. > > > > > > With the latest discussions on the Browse API and how to deal with > > (muti-dimensional) arrays … I think probably a notation: > > > > > > 5:BOOL[3..8] > > > > > > Would be better than: > > > > > > 5.3:BOOL[5] > > > > > > What do you think? > > > > > > Chris > > > > > >
Re: BOOLeans ;-)
Hi, Chris. I'm sorry to interrupt your trip. 1. Regarding "a coil is a single-valued boolean .. Not sure what the offset means here?" issue, I just tried it and it works like any other data type, but there are 2 small issues to deal with. (1) When we read the INT type, it returns a binary sort of "AB CD", while the BOOL type returns "BA DC", so we need to deal with the binary before reading the BOOL. (2) The Quantity needs to be added to Offset. 2. How to represent the offset and the number of arrays, I think it's fine, as long as it's clearly described. Christofer Dutz 於 2022年10月13日 週四 晚上10:10寫道： > Well, I guess mostly I‘ve seen it more treated like: If there’s no “..” > the number is the size of the array, … if there’s a “..” then the prefix is > the offset. And yes: the Golang approach is again very different to what I > have seen be used in industrial automation. > > Chris > > From: Sebastian Rühl > Date: Thursday, 13. October 2022 at 09:06 > To: dev@plc4x.apache.org > Subject: Re: BOOLeans ;-) > In some language I saw that being used as ranges: > > BOOL[5] would be one bool at index 5 > BOOL[:5] would be 5 bools till index 5 > BOOL[3:5] would be 3 bools from index 3 to 5 > BOOL[2:] would be all bools from index 2 > BOOL[:-1] would be all bools till the last index -1 > > So maybe I'm wrong, but when you write 5.3:BOOL[5] you mean > 5.3:BOOL[:5], right? > > Sebastian > > On 2022/10/13 13:40:08 Christofer Dutz wrote: > > Hi all, > > > > seems we got a PR where someone implemented my proposal for handling > Booleans ( > https://cwiki.apache.org/confluence/display/PLC4X/Cleanup+of+how+we+handle+all+the+bit-related+fields > ) > > For Modbus in Go (https://github.com/apache/plc4x/pull/545) > > > > I think we should probably finish some of the discussions on this and > document them in the project. > > > > With the latest discussions on the Browse API and how to deal with > (muti-dimensional) arrays … I think probably a notation: > > > > 5:BOOL[3..8] > > > > Would be better than: > > > > 5.3:BOOL[5] > > > > What do you think? > > > > Chris > > >
Re: [DISCUSS] how to read bool and bool-arrays?
Sorry, I forgot to answer in English, embarrassing
I also think this is a good choice.
Excuse me, is the following example with 17 bits a miscalculation?
5:BOOL: X (17 bit)
5:BOOL[5]: X (17 bit)
5.0:BOOL[5]: X (17 bit)
5.3:BOOL[5]: 000X0 (17 bit)
5.14:BOOL[5]: 00XX (16 bit) XXX0 (16 bit)
Also, there is another case, let me confirm, 5.5:BOOL:
0X00, is this correct?
Christofer Dutz 於 2022年4月29日 週五 下午5:12寫道：
> Almost forgot replying ... stupid when you read emails on the run ... they
> get marked "read" and you forget about them :-(
>
> I would personally opt for doing something similar to S7 ... that we add a
> ".{bit-address}" which is only valid if the datatype is "BOOL". This offset
> allows a value between 0 and 15.
>
> I would then also opt for starting at the highest level bit (the most left
> one) as bit 0.
> So, when reading, I would do this (X being "Using the bit": 0 being
> "skipping the bit"):
> 5:BOOL: X
> 5:BOOL[5]: X
> 5.0:BOOL[5]: X
> 5.3:BOOL[5]: 000X0
> 5.14:BOOL[5]: 00XX XXX0
> In the result the left-most bit would be index 0 in the resulting list ...
> with growing indexes while going right.
>
> Chris
>
>
>
> -Original Message-
> From: jl hong
> Sent: Mittwoch, 27. April 2022 05:42
> To: dev@plc4x.apache.org
> Subject: Re: [DISCUSS] how to read bool and bool-arrays?
>
> Hello everyone,
> I write to the bool value just now,
>
> 1、
> b := []bool{true, true, true, true, true, true, true, true, false, false,
> false, false, false, false, false, false} // Prepare a write-request
> writeRequest, err := connection.WriteRequestBuilder().
> AddQuery("field1", "46:BOOL[16]", b).
> Build()
>
> it will write 46 to
>
> 2、
> b := []bool{true, true, true}
> // Prepare a write-request
> writeRequest, err := connection.WriteRequestBuilder().
> AddQuery("field1", "46:BOOL[3]", b).
> Build()
>
> When the length is less than 16, it will "bad access: nil dereference",
> the reason is readWriteModel.CastModbusPDUError() not catch the **ModbusPDU
> type.
> I saw the child error is ModbusErrorCode_ILLEGAL_DATA_VALUE (3)
>
> 3、
> When the length is great than 16(I just tested 17), the result like 1、case,
> no effect on 47
>
> I just synchronize the information to everyone
>
> Łukasz Dywicki 於 2022年4月23日 週六 上午1:42寫道：
>
> > Hello Chris, Myhongk, Stephen,
> > I would say.. watch how others do it.. openHAB modbus binding for
> > example has an additional parameter of "offset", so you can read
> > status bit and ie. float value on remaining 15 or 31 bits separately.
> > While I haven't seen such strange encoding of floats (but I saw it in
> > CANopen), the bit encoded alarm flags are quite popular. Especially in
> > modbus land.
> > I see two ways to approach problem:
> > 1) force values to be read as an bit array, then you can adjust offset
> > in a caller code or define offset.
> > 2) define an offset parameter for fields, then we probably need to
> > think how to align that.
> > Bit is essentially a boolean so it should fly always without touching
> > how booleans work. I found it earlier that booleans are read as kind
> > of bitset, but that was (I think) aligned by Chris sometime ago.
> >
> > Cheers,
> > Łukasz
> >
> > On 22.04.2022 13:18, Christofer Dutz wrote:
> > > Hi Stephen,
> > >
> > > Well, it sort of touches that area ... generally big endian/little
> > endian handles the byte order ... so this would more have an effect on
> > the order of the bytes inside the register too. In general I would
> > love to handle BE/LE as an option on the connection string. So per
> > default it's Big Endian (As the spec says), but you could switch to LE,
> if you need to.
> > >
> > > Chris
> > >
> > >
> > >
> > > -Original Message-
> > > From: Stephen Snow
> > > Sent: Freitag, 22. April 2022 12:57
> > > To: dev@plc4x.apache.org
> > > Subject: Re: [DISCUSS] how to read bool and bool-arrays?
> > >
> > > Hi Chris and Myhongk, et al
> > >
> > > Depending on the processor (this would include embedded IIOT
> > > devices)
> > they could be big or little endian, which may complicate matters for
> > the modbus driver. Being able to set th
Re: [DISCUSS] how to read bool and bool-arrays?
我也觉得这个选择挺好的.
请问下, 以下的示例有17个bit 是 写错了吗?
5:BOOL: X (17 bit)
5:BOOL[5]: X (17 bit)
5.0:BOOL[5]: X (17 bit)
5.3:BOOL[5]: 000X0 (17 bit)
5.14:BOOL[5]: 00XX(16 bit) XXX0 (16 bit)
另外, 还有一种情况, 我确认下, 5.5:BOOL: 0X00, 这样没错吧?
Christofer Dutz 於 2022年4月29日 週五 下午5:12寫道：
> Almost forgot replying ... stupid when you read emails on the run ... they
> get marked "read" and you forget about them :-(
>
> I would personally opt for doing something similar to S7 ... that we add a
> ".{bit-address}" which is only valid if the datatype is "BOOL". This offset
> allows a value between 0 and 15.
>
> I would then also opt for starting at the highest level bit (the most left
> one) as bit 0.
> So, when reading, I would do this (X being "Using the bit": 0 being
> "skipping the bit"):
> 5:BOOL: X
> 5:BOOL[5]: X
> 5.0:BOOL[5]: X
> 5.3:BOOL[5]: 000X0
> 5.14:BOOL[5]: 00XX XXX0
> In the result the left-most bit would be index 0 in the resulting list ...
> with growing indexes while going right.
>
> Chris
>
>
>
> -Original Message-
> From: jl hong
> Sent: Mittwoch, 27. April 2022 05:42
> To: dev@plc4x.apache.org
> Subject: Re: [DISCUSS] how to read bool and bool-arrays?
>
> Hello everyone,
> I write to the bool value just now,
>
> 1、
> b := []bool{true, true, true, true, true, true, true, true, false, false,
> false, false, false, false, false, false} // Prepare a write-request
> writeRequest, err := connection.WriteRequestBuilder().
> AddQuery("field1", "46:BOOL[16]", b).
> Build()
>
> it will write 46 to
>
> 2、
> b := []bool{true, true, true}
> // Prepare a write-request
> writeRequest, err := connection.WriteRequestBuilder().
> AddQuery("field1", "46:BOOL[3]", b).
> Build()
>
> When the length is less than 16, it will "bad access: nil dereference",
> the reason is readWriteModel.CastModbusPDUError() not catch the **ModbusPDU
> type.
> I saw the child error is ModbusErrorCode_ILLEGAL_DATA_VALUE (3)
>
> 3、
> When the length is great than 16(I just tested 17), the result like 1、case,
> no effect on 47
>
> I just synchronize the information to everyone
>
> Łukasz Dywicki 於 2022年4月23日 週六 上午1:42寫道：
>
> > Hello Chris, Myhongk, Stephen,
> > I would say.. watch how others do it.. openHAB modbus binding for
> > example has an additional parameter of "offset", so you can read
> > status bit and ie. float value on remaining 15 or 31 bits separately.
> > While I haven't seen such strange encoding of floats (but I saw it in
> > CANopen), the bit encoded alarm flags are quite popular. Especially in
> > modbus land.
> > I see two ways to approach problem:
> > 1) force values to be read as an bit array, then you can adjust offset
> > in a caller code or define offset.
> > 2) define an offset parameter for fields, then we probably need to
> > think how to align that.
> > Bit is essentially a boolean so it should fly always without touching
> > how booleans work. I found it earlier that booleans are read as kind
> > of bitset, but that was (I think) aligned by Chris sometime ago.
> >
> > Cheers,
> > Łukasz
> >
> > On 22.04.2022 13:18, Christofer Dutz wrote:
> > > Hi Stephen,
> > >
> > > Well, it sort of touches that area ... generally big endian/little
> > endian handles the byte order ... so this would more have an effect on
> > the order of the bytes inside the register too. In general I would
> > love to handle BE/LE as an option on the connection string. So per
> > default it's Big Endian (As the spec says), but you could switch to LE,
> if you need to.
> > >
> > > Chris
> > >
> > >
> > >
> > > -Original Message-
> > > From: Stephen Snow
> > > Sent: Freitag, 22. April 2022 12:57
> > > To: dev@plc4x.apache.org
> > > Subject: Re: [DISCUSS] how to read bool and bool-arrays?
> > >
> > > Hi Chris and Myhongk, et al
> > >
> > > Depending on the processor (this would include embedded IIOT
> > > devices)
> > they could be big or little endian, which may complicate matters for
> > the modbus driver. Being able to set this as a parameter when using
> > the driver in an app being built which may talk to many modbus devices
> > of either endian arrangement would likely
Re: [DISCUSS] how to read bool and bool-arrays?
Hello everyone,
I write to the bool value just now,
1、
b := []bool{true, true, true, true, true, true, true, true, false, false,
false, false, false, false, false, false}
// Prepare a write-request
writeRequest, err := connection.WriteRequestBuilder().
AddQuery("field1", "46:BOOL[16]", b).
Build()
it will write 46 to
2、
b := []bool{true, true, true}
// Prepare a write-request
writeRequest, err := connection.WriteRequestBuilder().
AddQuery("field1", "46:BOOL[3]", b).
Build()
When the length is less than 16, it will "bad access: nil dereference", the
reason is readWriteModel.CastModbusPDUError() not catch the **ModbusPDU
type.
I saw the child error is ModbusErrorCode_ILLEGAL_DATA_VALUE (3)
3、
When the length is great than 16(I just tested 17), the result like 1、case,
no effect on 47
I just synchronize the information to everyone
Łukasz Dywicki 於 2022年4月23日 週六 上午1:42寫道：
> Hello Chris, Myhongk, Stephen,
> I would say.. watch how others do it.. openHAB modbus binding for
> example has an additional parameter of "offset", so you can read status
> bit and ie. float value on remaining 15 or 31 bits separately.
> While I haven't seen such strange encoding of floats (but I saw it in
> CANopen), the bit encoded alarm flags are quite popular. Especially in
> modbus land.
> I see two ways to approach problem:
> 1) force values to be read as an bit array, then you can adjust offset
> in a caller code or define offset.
> 2) define an offset parameter for fields, then we probably need to think
> how to align that.
> Bit is essentially a boolean so it should fly always without touching
> how booleans work. I found it earlier that booleans are read as kind of
> bitset, but that was (I think) aligned by Chris sometime ago.
>
> Cheers,
> Łukasz
>
> On 22.04.2022 13:18, Christofer Dutz wrote:
> > Hi Stephen,
> >
> > Well, it sort of touches that area ... generally big endian/little
> endian handles the byte order ... so this would more have an effect on the
> order of the bytes inside the register too. In general I would love to
> handle BE/LE as an option on the connection string. So per default it's Big
> Endian (As the spec says), but you could switch to LE, if you need to.
> >
> > Chris
> >
> >
> >
> > -Original Message-
> > From: Stephen Snow
> > Sent: Freitag, 22. April 2022 12:57
> > To: dev@plc4x.apache.org
> > Subject: Re: [DISCUSS] how to read bool and bool-arrays?
> >
> > Hi Chris and Myhongk, et al
> >
> > Depending on the processor (this would include embedded IIOT devices)
> they could be big or little endian, which may complicate matters for the
> modbus driver. Being able to set this as a parameter when using the driver
> in an app being built which may talk to many modbus devices of either
> endian arrangement would likely be beneficial. Byte swapping in PLC land is
> common in communication between PLC's/PC's and periphery devices or other
> control elements.
> >
> > I don't know if that is what you're referring to, but it sure sounds
> like endian issues I have encountered in the past (and still today).
> >
> > Be well,
> >
> > Stephen
> > On Fri, 2022-04-22 at 10:26 +, Christofer Dutz wrote:
> >> Hi all,
> >>
> >> Myhongk just brought up an issue in the Modbus driver, which I think
> >> could probably also come up in other protocols.
> >>
> >> When reading a BOOL or BOOL[] the driver generally reads chunks of 16
> >> bits (words). Now we need to define how we count the bits.
> >>
> >> Currently when reading a simple BOOL we do this (0 = skipped, 1 =
> >> read):
> >>
> >> 0001
> >>
> >> So, the least significant bit is the value and the ones before are
> >> skipped.
> >>
> >> When reading an array, we currently start at the end. So reading
> >> BOOL[6] would be this:
> >>
> >> 1100
> >>
> >> In this case we start at the most significant bits.
> >>
> >> Both variants have its logic and it's downsides.
> >>
> >> Downside by starting at the least significant bits is as soon as we
> >> read more than 16 bits.
> >> So, if we read BOOL[19] we'd probably have this
> >>
> >> 0XXX
> >>
> >> Where the indexes in the array would probably be:
> >>
> >> 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 X X X X X X X XX X X X
> >> X 18 17 16
> >>
> >> Or would it be different?
> >>
> >> Another option would be to start at the end of the last word read and
> >> to count "from right to left"
> >>
> >>
> >> If we start at the most significant bits, it would make things easier
> >> for multiple elements, as we'd have this for BOOL[19]:
> >>
> >> 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 X X X X X X X X
> >> X X X X X
> >>
> >> But we would have only read the register value: 32768 or 0x8000 as
> >> "True".
> >>
> >>
> >> Would be cool to know what's the default industry way to do thins (I'm
> >> sort of expecting an "it depends").
> >> Possibly we could make it configurable (Which would complicate things
Re: Reads of type bool have different results
Thanks for the reply, Chris.
1 Myhongk is ok, haha
2 It is my honor to be a regular contributor to open source projects.I'm
just worried if I'm up to the task.
3 Thanks for the detailed answer on BOOL type, I will try to fix this bug.
Let me confirm, 46:BOOL[10], it means read the last 1-10 bits, right?
For example, 10101010 10101010, the read is 10 10101010, in the program
like list[0,1,0,1,0,1,0,1,0,1]
Am I understanding correctly?
Also, please tell me where I can learn the define of BOOL[2] is getting the
last two bits of two registers
Christofer Dutz 於 2022年4月22日 週五 下午4:30寫道：
> Hi Myhong (Hope that's correct)
>
> First of all, welcome to our cool project ... I hope you'll like it here
> and become a regular contributor ;-)
>
> Regarding BOOL[2] getting the last two bits of two registers is definitely
> not the way it should be. It should be returning the last two bits of one
> register and only span to the next if reading more than 8. We should
> probably track this in an issue and fix it (if you've already got an idea
> ... PRs are always welcome :-))
>
> However not 100% sure how we should generally do this. Perhaps [1] should
> return the first bit and add lesser significant bits as the array grows. I
> think I did it the way it's currently implemented, as when using registers
> to store Boolean values I usually store 0 and 1 in them.
>
> Other protocols (s7) have the concept of a bit-address. Perhaps
> artificially extending the modbus protocol with this concept would be an
> option.
>
> Taking your example:
>
> 46.1:BOOL[2]
>
> Could then read two bits starting at the second-most significant bit.
>
> 0XX0
>
> Would that work for you? But in that case we probably should invert how we
> read "BOOL" from interpreting:
>
> 1 as true to 1000
>
> But not sure on how this would break other options.
>
> Chris
>
>
> -Original Message-
> From: 洪锦琳
> Sent: Freitag, 22. April 2022 10:16
> To: dev@plc4x.apache.org
> Subject: Reads of type bool have different results
>
> Hello everyone!
> First, thanks to Chris for his reply in my PR, so here I am!
>
> Issue:
> 1 When I read 46:BOOL[1], it will get the last bit of 46(2bytes).
> Here is the source code:
>
> github.com/apache/plc4x/plc4go/internal/plc4go/modbus/readwrite/model/DataItem.go
>
> case dataType == ModbusDataType_BOOL && numberOfValues == uint16(1): //
> BOOL
>// Reserved Field (Just skip the bytes)
>if _, _err := readBuffer.ReadUint16("reserved", 15); _err != nil {
> return nil, errors.Wrap(_err, "Error parsing reserved field")
>}
>
>// Simple Field (value)
>value, _valueErr := readBuffer.ReadBit("value")
>if _valueErr != nil {
> return nil, errors.Wrap(_valueErr, "Error parsing 'value' field")
>}
>readBuffer.CloseContext("DataItem")
>return values.NewPlcBOOL(value), nil
>
>
> 2 When I read 46:BOOL[2], I get 46 and 47, the first two bits
> of a total of 4 bytes.
> Source code:
>
> github.com/apache/plc4x/plc4go/internal/plc4go/modbus/readwrite/model/DataItem.go
>
> case dataType == ModbusDataType_BOOL: // List
>// Array Field (value)
>var value []api.PlcValue
>for i := 0; i < int(numberOfValues); i++ {
> _item, _itemErr := readBuffer.ReadBit("value")
> if _itemErr != nil {
> return nil, errors.Wrap(_itemErr, "Error parsing 'value' field")
> }
> value = append(value, values.NewPlcBOOL(_item))
>}
>readBuffer.CloseContext("DataItem")
>return values.NewPlcList(value), nil
>
> I thought it was 46:BOOL[1] to get the 2nd bit of 46, but the "[1]"
> match in the regular is "quantity". So, I'm not sure how to fix this
> problem correctly. Let's discuss it here.
> github.com/apache/plc4x/plc4go/internal/plc4go/modbus/FieldHandler.go
>
> generalFixedDigitAddressPattern :=
> `(?P\d{4,5})?(:(?P[a-zA-Z_]+))?(\[(?P\d+)])?$`
>
