Support for single bits.

[NIVA-IS-PSH]

From Issue #11 you state that the fins-nodes doesn't support read or write of single bits. So, if one wants to set/reset a single bit (e.g an output) one would have to first read the word in which the bit is located and then change the bit in the read word and write it back? Or am I missing something?

It seems though, that some parts of the code in your nodes "support" single bits. I tried to set address to CIO100.5 and data(number) "1" or "0", and the response msg was:

But the result in the PLC was that the hole word CIO100 was set to either 0x0001 or 0x0000.

[Steve-Mcl]

The node-red node part understands omron addresses however the fins client code is not developed for performing bit read/write.

It is not a priority for me as typically I avoiding reading and writing individual bits are it is very uneconomical in terms of network traffic.

Is this something you need or can you work around it?

Typically I try to encourage users to manipulate all status bits into single or consecutive WORDS and read them all in one go. This improves performance hugely when the bits are "littered" around the PLC. It also has a positive side effect in that all the bits being read/written become cross referenceable and in one place.

[NIVA-IS-PSH]

Thanks for your answer.

I think it is a matter of the "architecture" of one's system i.e. whether the Node-RED instance is like a "sole master" or one have a more "distributed" control of the system.

Reading is easier as one can just read a word and mask off the bits needed.

Writing is more difficult - especially directly to the PLC outputs if there are more than the Node-RED instance as a source for control - say one have a local HMI display which can control some output and then other outputs are controlled by the remote Node-RED instance. If two such bits are neighboring in the same word there is no safe* way to control those bits word-wise.

A workaround would be not to write to output bits directly but to control them via some working or holding bits in the PLC. I think that is more or less what you suggest. This slightly increases the complexity of the PLC program, though, but not at all a show stopper for our project

I'm not so concerned with the network traffic.

PS: And by the way, thank for the work you have put into this node its a great help for me already.

*)I realize my suggestion from yesterday (read > mask/change > write back) is not safe since the unaffected outputs/bits can't be locked between the read and the write operation.

[Steve-Mcl]

Hi again.

I have been playing with adding bit read/write functionality to the driver.

If I were to publish a beta to npm would you be willing to test?

Ideally you would test bit read and bit write (single bit and multiple bits) to DM, CIO, H, W & E_x areas.

Let me know if this is something you could support & I will make preparations.

[NIVA-IS-PSH]

Yes that would be great!

One thing though, I'm using the CP1L-E models. I noticed that the in the connection node the mode only support CS/CJ, NJ/NX and NV. It seems to work regardless. I'm not into the fine details about differences in the FINS-protocol between the various
models.

[Steve-Mcl]

The CP series is VERY similar to CS/CJ so should work (i just dont have one to test on)

Ok, so I have published 0.4.0-beta.0 to NPM.

To install you will need to run npm install node-red-contrib-omron-fins@0.4.0-beta.0 in your .node-red directory.

Please feedback on your testing success/failures & I will release to mainstream when you are happy.

Please do test read AND write to all areas - both BIT and WORD. Please verify the values are written to the PLC locations correctly using CX-Programmer to verify each address.

Please also test addresses at the high end and low end of the PLC (e.g. D10 and D32200 for example)

Cheers.

[NIVA-IS-PSH]

Great! Have installed the beta and just tested initially write and read of CIO100.01 - works so far.

Will get back when I have the result of the more systematic tests ready.

[NIVA-IS-PSH]

I have been testing a bit sporadic on various addresses and so far it is working and I am currently setting up an environment to test more systematically. I however see this message every time I deploy:

It is always coming from the last added fins node (write/read).

[Steve-Mcl]

Thanks for the feedback, I will attempt to fix and publish a fix in the next few minutes.

[Steve-Mcl]

@NIVA-IS-PSH could you please update to version 0.4.0-beta.1

npm install node-red-contrib-omron-fins@0.4.0-beta.1

Again, please feedback with your results - I am particularly interested in knowing that WORD and BIT write to various areas and addresses are confirmed to READ/WRITE to the correct PLC locations.

Thanks, Steve.

[Steve-Mcl]

@NIVA-IS-PSH Any update please?

[Steve-Mcl]

@NIVA-IS-PSH I have now published release version 0.4.0 to NPM - please update your installation.

If you find any issues please comment here or open a new issue.

cheers.

[NIVA-IS-PSH]

I am testing systematically through the various memory areas and alongside building a setup to reproduce the tests with results automatically where applicable.

So far I have made the following bit read and write tests on the 0.4.0 version:

READ TESTS

• READ CIO0.0 count 12 first input block read with various "physical" states of the individual inputs: OK

WRITE/READ TESTS Written both 1 and 0 to the following locations and read back after each write to verify

- CIO3.0-15 count 1 unused input bits:  OK
- CIO10.0-15 count 1 unused input bits:  OK
- CIO100.0-7 count 1 first output block. Also checked outputs "physically" on device : OK
- CIO199.0-15 count 1 unused output bits: OK
- CIO3050.0-15 count 1 1-1 link area :OK
- CIO3150.0-15 count 1 Serial PLC Link Area :OK 
- CIO6000.0-15 count 1 work area : OK
- D0.0-15 count 1 memory area: OK
- D3000.0-15 count 1 memory area : OK
- D32000.0-15 count 1 memory area : OK
- H0.0-15 count 1 holding area : OK
- H200.0-15 count 1 holding area : OK
- H511.0-15 count 1 holding area : OK

The above tests does not include verification via the CX-programmer, but I plan to do this as well and also testing with words.

I have seen two issues so far: For the Auxiliary area I get errors if I try to address above 511 both read/write and bit/word.
The PLC returns end-code 1103 for addresses above A511. I tried a little with a python fins-module* and there it seems to work above address 511. (my model is a CP1L-EM30-DR)

For the counter and timer areas there seems to be no way to address the completion bits. This is in line with your description that follows the nodes, though. Only the read/write of PV-words are mentioned

*) https://aphyt.com/index.php/omron-fins-driver-in-python-3

[Steve-Mcl]

Hi @NIVA-IS-PSH

In CS/CJ Aux area range is only A000 to A511 so I cant test however, according to this manual the address memory location is exactly the same for addresses A0 ~ A477 and A478 onwards for CP, CJ and CS

My point is, if A478 works, the A512 should also work. Most odd.

Could you confirm with CX Programmer a hand full of A registers match up?

e.g.

Address	FINS READ Node	CX-Prog Value
A0	...	...
A447	...	...
A448	...	...
A511	...	...
A512	...	...

Obviously if the value is zero it will be difficuly to confirm for sure (though many A areas are writable so try setting them in the PLC then re-reading using FINS Read node.

---

As for the Python3 code - I am very surprised that works at all for A areas as they don't offset the real memory address area for A478 and above. My suspicion is when you request A512 from that python code you are getting

Scratch that - I think i have misinterpreted the manual.

I will publish a fix shortly.

---

as for counters, yes, I have not yet decided a suitable way to differenciate between addresses C100 for the PV and C100 for the bit value. I might have to add a checkbox [x] or dropdown options allong the lines of return timer/counter PV or bit status to the UI - any thoughts?

[Steve-Mcl]

@NIVA-IS-PSH I have published and update V0.4.1

Can you please install and try again...

Address	FINS READ Node	CX-Prog Value
A0	...	...
A447	...	...
A448	...	...
A511	...	...
A512	...	...
A959	...	...

A0 ~ A447 are readonly (so if A447 is zero, try finding an A in the high 400s area that has a value in it) You can write to values in A448 ~ A959 in CX-Programmer - please test some of the lower and higher ones.

[NIVA-IS-PSH]

@Steve-Mcl I made Node-RED flow that reads every 10th A-word (A0, A10, A20.. etc.) from my PLC in stopped mode. I then download all A-words by the CX-Programmer and filtered out all zero words on "both sides":

ADDR.	FINS	CX	OK
A0	DF59	5A2E	FALSE
A40	03C2	03C2	TRUE
A90	1308	1308	TRUE
A100	021A	021A	TRUE
A110	021A	021A	TRUE
A280	0020	0020	TRUE
A300	0003	0003	TRUE
A310	0518	0518	TRUE
A450	00B0	00B0	TRUE
A460	0082	0082	TRUE
A470	0059	0059	TRUE
A510	3607	3607	TRUE
A520	2106	2106	TRUE
A580	0F00	0F00	TRUE
A640	0002	0002	TRUE
A660	1308	1308	TRUE
A720	3607	3607	TRUE
A730	1618	1618	TRUE
A740	2106	2106	TRUE
A959	7777	7777	TRUE

NOTE: A0 is a 10-ms Incrementing Free Running Timer that never stops. 7777 was prefilled in A959 manually from the CX-programmer on beforehand. I'll post further results (bits and write) when ready.

Regarding address notation for counter and timer completion bits: I would suggest to use the same notation as for all other bits and add to the documentation that only CXXXX.0 or TXXXX.0 is valid and have the node issue an error if an address is [C|T][XXXX].[>0]

[Steve-Mcl]

Good feedback. Thanks.

I'll consider the timer counter bits.

Tbh I'm thinking that accessing T100 should be changed the return the bit status and some other syntax like T100.PV to access the PV?

Or perhaps T100/C100 accesses bits and TIM100/CNTR100 Accesses PV?

thoughts?

[Steve-Mcl]

Hello @NIVA-IS-PSH

I have been busy going through the node with a fine tooth comb.

I have fixed several issues and added support for accessing T/C bits e.g T100 or C250 and T/C PV via TIM100 or CNT100

I have also added several new nodes to the pallete...

• read - read 1 or more WORDs or bits
• write - write 1 or more WORDs or bits
• fill - fill 1 or more consecutive addresses with a value
• read-multiple - read several disparate address values
• transfer - copy 1 or more data values from one memory area to another
• control - this has the following functions...
  • Get PLC Status
  • Get PLC Unit Data
  • Set PLC STOP/PROGRAM mode
  • Set PLC RUN/MONITOR mode
  • Get Clock
  • Set Clock

https://www.npmjs.com/package/node-red-contrib-omron-fins/v/0.5.0-beta.2

I am confident this will be the last of the changes before I publish an update.

I would be most grateful if you would install npm install node-red-contrib-omron-fins@0.5.0-beta.2 and continue your testing.

Many thanks for the support.

EDIT... I also added support for TCP connections.

EDIT2... One visual issue you might notice (that i will resolve before publishing release) is that an error (e.g. bad address) on one node now propagates the error status to other FINS nodes - please ignore this visual quirk for the time being.

[Steve-Mcl]

@NIVA-IS-PSH I have made one last beta before publishing for release.

https://www.npmjs.com/package/node-red-contrib-omron-fins/v/0.5.0-beta.3

I would be grateful if you could install and feedback.

Thanks, Steve.

[NIVA-IS-PSH]

Hi Steve, I have installed 0.5.0-beta.3

I have done the same tests as here https://github.com/Steve-Mcl/node-red-contrib-omron-fins/issues/13#issuecomment-868301586 (Not the physical tests on inputs and outputs though. As the last week I have not been in the office where the PLC is located ) and here https://github.com/Steve-Mcl/node-red-contrib-omron-fins/issues/13#issuecomment-869057584 All in both UDP and TCP-mode

I have tried the control node without issues:

• Read CPU-unit Status and CPU-unit Data
• Set and read the clock
• Set mode to stop and run
• Tried connect/disconnect (although I haven't fully understood the "concept" here)

Tried little bit with Transfer and Read Multiple in the D area without issues.

I have varied above between TCP and UDP but not every combination

Addressing DR, IR, C and T does not work. I get End Code 1103 " Address range error."

Extended areas: don't have any extra mem-module installed and the CP1L seems to support memory cassettes for backup only?

Regarding addressing of the counter and timer completion bits: Maybe it is not such a good idea to address it as C|Tx.0 as I suggested earlier. This could be confused with the 0th bit of PV word. (although there is no FINS-method for addressing individual bit til the C/T PV words? ) But since it is a bit I think the "dot-notation" should be used. What about Cx for counter x PV word and Cx.cb for counter x completion bit: C28 is PV word of counter 28 T22.cb is the completion bit of timer 22.

[Steve-Mcl]

Tried connect/disconnect (although I haven't fully understood the "concept" here)

For OEMs who wish to provide a solution but dont know the PLC address up front, this permits a customer to connect with PLC parameters provided from, for example, a dashboard admin page. Also, for sticky situations, being able to issue a disconnect/connect might solve a transient issue.

Addressing DR, IR, C and T does not work. I get End Code 1103 " Address range error."

RE: DR, IR, I seen this also & I triple checked the address bytes and cant fathom it out. Might give it one more look Found the issue. I'll publish 1 last beta with this fix.

RE: C and T in this beta, they should return Counter/Timer completion bits. I have re-worked it to do C0/T0 = PV, C0.cb/T0.cb = completion bit - but I think it looks ugly :(

I'll publish final beta after considering the C/T completion bit & deciding on a final solution.

I am considering the following solutions (undecided on which to chose)...

• C0 = completion bit, C0.PV = PV
• C0 = completion bit, CPV = PV
• C0 = completion bit, CNT0 = PV
• C0.cb = completion bit, C0 = PV
• C0.bit = completion bit, C0 = PV
• C0.0 = completion bit, C0 = PV

Comments are welcome.

[NIVA-IS-PSH]

For OEMs who wish to provide a solution but dont know the PLC address up front, this permits a customer to connect with PLC parameters provided from, for example, a dashboard admin page. Also, for sticky situations, being able to issue a disconnect/connect might solve a transient issue.

Ah ok, that might come handy! However, you specify the option object as; {host:string, port:number, timeout: number, DNA:number, DA1:number, DA2:number, SNA:number, SA1:number, SA2:number} Since you now have introduced TCP, shouldn't there be a "protocol" item as well?

RE: C and T in this beta, they should return Counter/Timer completion bits.

Yes you're right, read C|TX does work and return the state of the completion bit. By the way, is write to the completion bits possible ? I does not (or only in very rare cases) make sense to do that, I suppose? But write to the PV-words would make sense, wouldn't it?

Addressing notation: To keep it consistent with the notation for other memory areas I think C0.somthinge for the bit and C0 for PV "cb", "bit" looks ok to me. If it is to be a number then maybe C0.16 would be a solution? Not 0-15 - as mentioned - to prevent confusion with bits in the PV-word

[Steve-Mcl]

I'm close to feeling C0.bit might be the way to go. Still mulling it over.

Since you now have introduced TCP, shouldn't there be a "protocol" item as well?

There is, I must have forgotten that in the docs.

If you look in examples (ctrl+I) for this node, there is a control demo that does this.

[Steve-Mcl]

@NIVA-IS-PSH

Hoping this is the last beta - node-red-contrib-omron-fins@0.5.0-beta.4

I have addressed the documentation and change T|C bit access to .x e.g. C0.x T0.x. C0 and T0 still access PV (still don't love it but .x was chosen for compactness and x reminds me of a input/contact/bit (similar to how y signifies and output) - I am still willing to change this if we feel .bit or .cb or something else feels better.

I have updated the built in demos to match latest beta.

A few other internal changes have been made to improve re-connection in the event of an issue, also to ensure event listeners are removed when nodes are removed from the editor, and a few other things I forget.

I have tested it and will leave it running, polling several commands overnight,

🤞

[Steve-Mcl]

@NIVA-IS-PSH - it is done. Released.

V0.5.0 now on NPM and flows lib.

Thank you for your support.