Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by bobnorway

  1. Try not to think so much about the language.

    Rather think function, a plc is primarily a digital machine, strings are not.

    The ladder program is a digital expression.

    Pushing the 'Blue' button should set a blue flag bit.

    Multiple button choices set mutiple respective flags.

    The program sums up the flags and will result in only one true result/action.

    Grouping the buttons on screen will allow you to focus the operators attention.

    The flag activates the button background color to indicate the one choosen.

    Pull down list choices are not always easy to use on a small touch screen without a mouse.


    Is your operator using gloves?

    Is the on screen text in the operators first language?

    Is the operator color blind?

    Does the operator need glasses to read the text?

    Pehaps an actual machine related graphic symbol would illustrate best.

    Happy Programming 


  2. I think this problem is not a very good fit for a newbie.

    Decoding a large variable ascii transmission could better be done with a unit which has more

     string tools for handling the data blocks.

    Perhaps then sending just the extracted value to the unitronics.

    I assume it is always the same ODBIS code value you require?

    Incidently the documentation says the telegram is sent every second not every 7 seconds.


  3. I agree with Flex727

    a file is as delivered to the customer should not be changed, updated or modified.

    looking at a file and exiting without saving is not modifying it.

    version control is best done with date and time.

    what if you bought a house and the bank changed the date after you had signed the contract?



    • Like 1
  4. add the values from first byte to the last byte to the sum.

    (1+2) H0b + H00 = H0b

    (S+3) H0b + H01 = H0c

    (S+4) H0c + H00 = H0c

    (S+5) H0c + H00 = H0c

    (S+6) H0c + H00 = H0c

    (S+7) H0c + H00 = H0c

    (S+8) H0c + H00 = H0c

    (S+FF) H0c + Hff = H0c          mask off values larger than one byte)

    (S xor 3c) H0c xor H3c = H30

    The H3c is probably to ensure that the check sum which is the last byte is not zero


  5. PLC PID is a mathmatic function not hardware based.

    Most PLC PID implementations are for regulation 0 - 100%, or reverse for cooling.

    100% of 'what' to do 'something' is not realy their bussiness.

    This makes the PID function "universal".

    It is your job to scale the "footballs per day " PID input to 0-100%,

     and then scale the PID output from 0-100% to "footballs".

    In your case with the PID output do a simple scaling (PIDX * 2) = 0-200%

     then subtract (PID2X -100)  gives a range of -100 to +100

    have a good day.


    • Like 1
  6. I whole heartedly agree with "almost never", but as the saying goes "never say never"

    When working with most sensor devices you have a finite range 0-20ma = 0-100% or 0-10bar or 0-12feet

     using whole number math insulates you from idiot number results like a 1234% full tank,

    it simply can't happen.

    However you are trying to average positive and negative numbers, this would be a good place to have an

     exception to the rule of thumb  and use real numbers.

    In "the old days" plc's could not handle real numbers well and used a long, long time to calculate them

     this gave long CPU cycle times and not particularily good results.

    Todays plc's have much better cpu's and can handle real numbers pretty well. 

    We are never trying to calculate the budgjet deficite of a world economy so 8 significant places

     is good enough for us in real life usage.

    Unitronics scaling is really easy min - max what you get input to min - max what you want output.

    I would like to suggest that you filter out the unresonable values given by the arm passing in front.

    If input > 123456 mm then goto end

    run your stacked array average only with ok numbers.

    "garbage in garbage out" 


  7. Standards

    Once apon a time in the 'good old days' there was a standard to ease interfacing of different equipment together.
    It was called 'RS-232' for simple and effective serial interfacing.
    The voltage was a given always a -12 to +12 volt swing, a safe voltage with reasonable noise immunity.
    Then one fine day in order to reduce parts count it was implemented as 0 to +12 volt.
    Still almost as good and cheaper.
    As terminals became PC's the parts count was reduced so the readily available 0 to +5 volt
     was used as a power source.
    Not quite as good but even less expensive.
    The lower voltage allowed for a higher communication speed.
    Sometimes one end of the Com line was one type and the other was a different type.
    This lead to problems but neither end manufacturer was 'responsible' so it continued on.
    The Standard called for a 25 pin 'D' sub connector allowing for plenty of future space.
    This configuration gave full hardware hand shaking, these hardware lines could be tied
     up or down to reduce the parts count.
    Tied lines were not as good but are even less expensive.
    With the reduced pin count it was possible to use a 9 pin 'D' sub connector.
    This reduced cost and space requirements.
    Luckily throughout all of this development there has always remained a 'constant'
     which is one 'transmit', one 'receive' and one 'ground' pin.
    Within the Standard 25 pin version pin 2 TX, 3 RX, 7 Gnd are used.
    Of course the Standard 9 pin version is different 2 RX, 3 TX, 5 Gnd.
    The 6 additional handshaking lines are also moved around.
    These are the 'Terminal' standards, the other end is a 'Modem' standard with 
     the functions of pin 2 and 3 reversed.
    Naturally if it is for a PC to PC Com line this will not work and the infamous 'Null Modem'
     crossed cable is used.
    PC's are often supplied with male connectors which may require a female - female adapter.
    Often a male - male adapter will also be necessary and a 25 to 9 pin adapter is very usefull
     to complete the connection.
    A break out box is a very handy tool allowing individual pins to crossed as required until
     the connection works.
    In real life sometimes one or more of the pins are accidentally left floating this gives
     all sorts of intermittant trouble.
    Grounding two electrical machines together via the serial connector sometimes produces
     a ground loop which plays havoc with the system.
    To avoid this danger some manufactures don't connect the ground pin to the chassis!
    The original 'standard' had a cable shielding connection to the connecter shell but
     inexpensive connectors made of plastic defeated this function.
    So the 'RS-232' Standard implementation can be 25 or 9 pin, male or female, 12 or 5 volt,
     send or receive function, handshake or not, grounded or isolated.
    I should mention 'Standard' speeds, baud rate (bit) 50 and upwards, 
     Mark and Space (1 and 0), Start and Stop bits, 5 to 16 bit per character, '
     Standard' character coding, check sum controls, Com protocols, point to point or multi drop.
    So it may take a while to get a 'Standard' system online.

    a good read http://www.machine-information-systems.com/RS232_Pinouts.html
    and also https://en.wikipedia.org/wiki/RS-232

    Bob Clarke

  8. Not to discourage you but your task is difficult.
    RS-485 is a "recomended standard" it comes in both 2 and 4 wire versions.
    Mixing different suppliers, hardware interfaces, software protocols, 
     all at once will be a challenge.
    Things like a the standard definition of high byte low byte position, 
     and starting count position, is 4000 or 4001 the first byte?
    Neither Siemens nor Unitronics are "True" Modbus followers.
    Read up on what Modbus should be and what the supplier has
     actually implemented.
    All of these problems must be overcome before your own control
     logic can be effective.

    I would strongly suggest you break the problem down into solvable portions.
    Get the RS485 hardware right first and then get the 
     Modbus to Modbus protocol right independantly for each supplier.
    The quickest and best way is using something which has been proven to work.
    Use Siemens to Siemens and then Unitronics to Unitronics to solve some 
     commumication without to many unknown factors..
    Use a Modbus analyser to debug and see what is 'really' going on.
    Polling requires that communications both ways is correct.
    Watching a cyclic broadcast will be simpler to start with.
    Then when you finally have a feel for this you can hook the
     two different systems together and tweak it up.

    Good luck


  9. There is NO! warning given that updating pc software from 1.25 to 1.28 requires a re-load of the plc!

    A quick program change for me has evolved to an hour long hasle with: (1) ethernet cable no connection!,

     (2) usb cable no connection,  (3) then to usb memory stick! 

     First by pc programming a memory stick then plc programming from uniapps takes time!

     And if I didn't happen to find a 'correct' stick to do this with in my bag?

    Dear Unitronics the plc control is serious business! Damaging the customers production line costs money!

    You can NOT play with systems in this way! 

    Any software version change which is so serious must be preceeded by a clear warning.

    Bob Clarke




  10. I quite agree on the PDF as absolutley the most usefull format, no argument there.

    However my problem is that in many cases the resulting PDF is unreadable.

    Failing on pagination for longer functions and on width for more complex ladder statements.

    The is no title field nor any page numbering to pull it all together.

    I would love to see some way to insert a formfeed in the code giving me a clear sectioning of functions.

    The poster option doesn't really help all that much and results in something impossible to

     use in a binder notebook.

    It may well be that Adobe is not helping much here but it actually can't change the source file.

  11. I think that Unitronics should put some real effort into this.

    Good documentation is a major part of good programming.

    Some control over boarders (top, bottom, left, right) and page numbers would help quite a bit.

    Print all fails miserably from function to function.

    Individualy printing each function does work better but takes great effort to get a readable result.

    That said the screen capture does give a better result quicker than many other plc/panel programs.

  12. I have problems printing program documentation.

    The program editor print does not seem to handle paging of modules correctly.

    Short modules are pretty reasonable but longer ones also get printed all on one page. 

    This results in a scaled font of microscopic size which is unreadable.

    I've tried all the combinations of fit size scale etc. without success.

    Any tip on how to do a readable document?

  13. removed everything, rebooted, reinstalled.

    same problem it is possible to "fix" the SQLserver but it will not stay fixed.

    a new install of SQLserver checks ok but does not survive a reboot of pc.

    the unilogic diagnostic is not happy nor is the unilogic.



  • Create New...