An under discussed topic in PLC system design
is documentation and register mapping.
Unlike other systems, PLCs and their client devices, communicate with registers.
Registers are blocks of memory, and data type effects the number of blocks
used. No big deal youre thinking, everything is like that. And youre right!
but PLCs map directly to memory locations.
So when youre planning a project, you need to know the data types of every calculation,
every step, and where every register will map to. Need? ok, maybe not need, but if you fail to
define all the steps, want to add additional calcululations, or add features later,
It is my sincere hope for you, that every register is mapped in a spreadsheet.
PLCs dont play nice accross platforms typicaly. Youre forced to use a specific operating system,
and reading the files output by any particular OEM software may not be readable outside the platform / software.
I've learned this first hand, programing PLCs in Linux, without OEM support.
So, I define my methods early.
The very first thing I think about is what I call endian. How bits and bytes are packed into memory.
PLCs only really know about Registers. Everything is a register. If you want to read a bit, that is
a segment of a register. if you want to read a string, the number of registers is defined by the length of the string.
Datatpyes like float, double, are 2, or 4 registers, and how you access those registers matters.
When youre reading data, you need to know the starting registister, and what direction to read the succesive registers in.
If youre not working in a larger orginazation, you can just pick something.
if youre working in an enviornment where one order is perfered over the other, I'd reccommend keeping the pattern.
What gets really confusing, is when the endain changes from one software to another.
The next thing I do is define starting registers for multi-register datatypes.
This is usialy even or odd numbers. While it is not critical, it is useful to be able to
look at a block of registers, and know where variables start and end.
For all my projects I put the first register for a multi-register datatypes on an even number.
This makes keeping track of things easier in the long run.
next, I would recommend, mapping your registers in a spreadsheet, or at least creating workspaces.
I almost never do this at the start of a project, and I always wish I did.
next I write out all my formulas, and the number of steps required to do an operation.
You want to keep datatypes in mind, and how many registers each datatype uses.
have to sum 3 numbers in ladder logic? Not so fast! You will have the option to sum 2 numbers,
then store the result, and at 1 more number. Thats 4 registers if youre using words (16bit register)
8 if youre using floats, and 16 if youre using a double. Where does the temporary sum live?
Do you put the final result in its own block of registers, or read the last step of the summing
calculation?
while its trivial initialy, for simple equations, or short programs, as your progams become more complex,
keeping track of where every step in the process is becomes crucial.
#################################################
In this project, the method I am using to read and write data to and from the Arduino is via an abstraction
of performing operations on the arduino, then reporttng data back in 16bit registers.
To do this, I need to know how the PLC expects to read the data I will provide from sensors and communication busses,
and map it out accordingly, so the PLC / HMI or other devices in the PLC system can read it.
Internaly, on the arduino, I have a bit more freedom to do things like read 3 registers at once, and sum them all in the same step.
To ensure that process goes as smoothly as possible, I will now define my basic functionality.
I am only going to support big endian for now. or the starting word is small, the the next numerical register is the upper byte(s) of the successive datatype.
analogReadWord(pin,register) returns a single analog word to the register
analogReadFloat(pin, register) returns 2 regisers to PLC
digitalRead(pin, register) returns a bit, or bcd value to the PLC
functions and operations:
The PLC normaly does all the math, but its the arduino in this project.
Fucntions should be declared with a datatpye in the name.
I'll make some general purpose functions to convert from bits to words, words to floats, etc.
The goal is to read data from the PLC / HMI, process it on the arduino, and return a PLC ready datatype.
# For writing values back, beyond simple IO operations, I may need to track specific device details, like Rx, Tx, enable / disable, or status of specific sensors.
This is where keeping a spreadsheet should be really helpful. Ideally, I would us the PLC to perform functions on the return values.
but the PLCs, I have also have much more memory that the arduino I am using.
PLCanlogWriteWord(output register, value) -> analog PLC device output.
PLCdigitalWrite(output register, value) -> PLC output contacts
PLCreadInputs(input register, value) -> PLC input status.
PLCspecialNAME(register,value) -> functions defined for specific PLC internal functions.
## bus communication:
bus coms suck on the PLC, but if its supported, Im not going to mess with it.
This is bacnet, MQTT, Modbus, TCP and a couple others I never think about.
SPI,i2C, and CAN are not supported on my PLC, so I will have to think about it eventualy.
## networking.
Ok I just said Im leaving the PLC to handle specific communications, and my current deployment model is using ethernet. its reasonalble to think we could do both serail and TCP.
NETWORK:
192.168.1.2 --PLC
192.168.1.10 --My computer
192.168.1.20 --HMI
192.168.1.50 --Arduino
192.168.1.7 --Opto22 Groov Rio
###Departure from conventional models.
I like to plan these things out, but Im also not very patient.
Normally, I would know what my project does, before I build it.
Im trying to plan out tests, for compatibility, and use application,
without knowing what the hiccups will be along the way.
There could be a glitch in this plan. This is all very fringe, and niche theoretical.
# I dont want the PLC to do anything except its special internal functions, control IO, and act as an interface.
# The ARDUINO will to all the calculations, and handle its integrated busses / IO.
# The ARDUINO will interface with all client IO, but im still going to treat the PLC like an output.
** better Go find some hardware.
############################
Well. I really tried to use the Arduino App Lab today.
I took careful note of a few things.
When you sign up to use the App Lab, it changes your system password. Mine was set, before running the app lab, so I noticed right away.
Does this thing dial home or make an account on a remote server?
God I hope not.
Well, I rewrote my i2C rotary encoder code with Monitor.print.
Aruino App Lab doesnt have find and replace, in the code editor, so that was tedious.
It took forever to compile then still wouldn't communicate on a serial port inside the app.
So then I wrote up a hello world sanity check. 
.
it ran on the serial port, but was constantly disconnecting
after every communication it disconnects. maybe there is something wrong in my implementation.
Serial.print would open a connection and stay open. so maybe there is something where the Monitor is closing, or I can tell it to say open.
the internet claims it is arduino-cli monitor -p /dev/ttyHS1 -b 115200 --watch