@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
          @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@


    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
                  =@@@@
                  @@@@
                 @@@@
                @@@@              @@@@
               @@@@                @@@@@
              @@@@@                 @@@@@
             @@@@@                   @@@@@
            :@@@@                     *@@@@
            @@@@     :@@@@@@@@@@@@@@@@@@@@@@
      @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
      @@@@@@@@@@@@@@@@=                   @@@@
                                           @`

                 [deroad's  blog]
                      [home]

# 2019-11-18 | Simatic S7-300/S7-400 - rant
{
  I have never seen such mess in a bytecode like for this PLC system.
  but first thing first:
  simatic step 7 is a programmable logic controller (PLC), made by siemens.
  essentially is a computer commonly used in commercial and industrial control applications.
  the cpu understands (interpret) byte-code that work in a similar way as the JVM one, so it has accumulators,
  timers, counter and etc..
  all the instructions can be found in siemens C79000-G7076-C505-02 statement list (STL) for S7-300 and S7-400
  programming manual.

  why is a mess? well a PLC job is just to control I/O signals received by the hardwareto do stuff.

  PLCs are standardized by the IEC 61131 norm and these norms defines also the "PLC language";
  these are usually programmed via some particular commercial applications like labview and the
  language is graphical.
  labview programming

  the bytecode itself doesn't have a common logic, if you start looking from the first bytes (see
  bytes from 0x00 to 0x5C well it kinda looks like having a structure, but then seems whoever was
  working on its definition got a stroke and rushed to finish the job by releasing some really messed up and ridiculously unnecessary complex/optimized operations.

  i want to make an example: a PLC has many way of defining a date; in the bytecode one is just
  loading in the accumulator integers, for example you can load/save the date 2019-11-18T01:02:03.000Z 
  by pushing in the stack 2019, 11, 18, 1, 2 , 3 and 0; but for some reasons they wanted also to have another
  format which is defined by the following math formula:

  f(x) : (x - 631152000) / 86400

  where x is the date in epoch format (epoch in seconds).
  why this weird conversion? because it "fits" in 16 bits.
  ofc, there is another type too, which is based in code based dates, like those used by manufactures (usually called
  part number) to know which parts has defects and when they got out of the factory.

  maybe i'm exaggerating, but this looks totally unnecessary to me; the byte-code supports 32bit values, i'm sure adding support for a proper date format in epoch would be much easier.

}

# References:
  Siemens C79000-G7076-C505-02 Statement List (STL) for S7-300 and S7-400 Programming Manual
  http://data.proidea.org.pl/confidence/9edycja/materialy/prezentacje/FX.pdf
  https://gitlab.com/nnaumenko/mc7