Shop OBEX P1 Docs P2 Docs Learn Events
towards a P2 PLC - Page 16 — Parallax Forums

towards a P2 PLC

11112131416

Comments

  • RaymanRayman Posts: 15,358
    edited 2025-06-16 13:19

    @"R Baggett" Know of an inexpensive device that would be a good test as a Modbus TCP slave?

    Probably no such thing as in inexpensive Modbus TCP master device, right?

  • That's true. all the established industrial stuff is pretty salty. My use case would be WAGO 750-362 and the whole family of 750 series modules that can be attached to it. If it would be helpful, I could send you one and a couple of I/O modules. It's implementation of Modbus TCP is, I am told as close as compatible with with the 'standard' as it gets without saying 'Modicon' on the front.. PM shipping address if you want it.

    I would also point out that Codesys IDE is free and comes with a soft controller for Windows and Linux (Even Raspi) that will run unlicensed for 1 hour or so between restarts. It supports Modbus TCP as master, and I think slave as well.
    Sadly, the IDE is Windows only.

  • dMajodMajo Posts: 860

    @Rayman said:
    In the future, would like to connect this P2 powered "PLC" for this subsystem to an actual Siemens giant PLC that is going to control everything.
    Plan is to connect using ethernet driven on P2 side by a Wiznet module.

    No idea if that is going to work though...
    Guess need to research that...

    With Siemens S7-300/400/1200/1500 series you can do nearly everything. Beside profinet you can also use raw TCP/UDP connections that you setup in the network config to pre-allocate resources or build on the fly during the program execution.
    In worst case you may need a CP (Communication Processor card) that means that you will need to add its communication FBs/FCs to your S7 program while the CPUs supporting Ethernet have them already in the OS in form of SFCs/SFBs.
    Some CPs supports also FTP server which means you can decide what DBs are available through it and you can transfer its content in both directions with any FTP client.
    I've communicated already with nearly everything from ESP32/Tibbo modules to various T&M instrumentation (PSU, SA, DAQ, MSO, ...) using SCPI commands.
    With mine CPU417-4 + CP443-1Adv I even controlled (through LAN) a Denon AVR4311 and Samsung UE55ES8000Q smarttv as proof of concept.
    So no issues at all, it will work for sure.

    And ... the CATegory on LAN cables basically indicates the bandwidth while for shielding grade you need to look at its type ( [S|F]/[S|F|U]TP) as AjL have already correctly explained

  • dMajodMajo Posts: 860

    @Rayman said:
    @"R Baggett" Know of an inexpensive device that would be a good test as a Modbus TCP slave?

    Probably no such thing as in inexpensive Modbus TCP master device, right?

    Have a look at Tibbo EM2001 boards (eventually with its WA2000C add-on for WiFi and BLE). Very Easy to program. I've never used them with Modbus, but IIRC they have also Modbus TCP gateway/master/slave examples. When I need something done quickly I many times use the EM2001 or WM2000

  • RaymanRayman Posts: 15,358

    @dMajo Thanks! Think the S7 is what they are looking at. Good to know there are many options.

    Still thinking Modbus TCP is way to go, and looks fairly simple to implement with Wiznet.

  • RaymanRayman Posts: 15,358

    Found a Modbus slave code that just got to compile with FlexProp:
    https://github.com/cwalter-at/freemodbus

    Also, found this modbus tester for PC side here:
    https://www.modbustester.com/#download

    So, thinking can make this happen...

  • TubularTubular Posts: 4,731

    Thats a good find Ray

    We traditionally use that 'cas modbus scanner' but I think what you found is better

  • RaymanRayman Posts: 15,358

    @Tubular Ok, downloaded that one here: https://store.chipkin.com/products/tools/cas-modbus-scanner

    The Codesys one looks fancy, but they don't seem to allow us USA people to download it...

  • @Rayman said:
    @Tubular Ok, downloaded that one here: https://store.chipkin.com/products/tools/cas-modbus-scanner

    The Codesys one looks fancy, but they don't seem to allow us USA people to download it...

    They are a little funny about it, but it can be DLed after making an account. I think your Modbus tester is a better way to go. Codesys is non-trivial to learn and set up.

  • RaymanRayman Posts: 15,358

    So, found a document on Modbus RTU (and others) here:
    https://modbus.org/docs/PI_MBUS_300.pdf

    From what I'm seeing, the protocol is very simple but the C code found so far is very obfuscated for such a thing. Guess it's so can be used on any device (except P2, of course). Also, meant to be interrupt driven.

    Might just implement this in simple spin2 with a dedicated cog and no interrupts.
    This seems like an important enough thing to deserve its own cog...

    Guess we'll see how this pans out...

  • MicksterMickster Posts: 2,795

    I also have a bunch of that Tibbo product. It would be cool to have a compatible motherboard with a P2. Instant modular P2 PLC right there and professionally packaged.

  • RaymanRayman Posts: 15,358
    edited 2025-06-21 18:53

    Thinking a PLC thing should have a display. But, might be the only one who thinks so...
    Still, maybe this is what multiple cores allow one to have...

  • depending on the orientation and resulting top face of the device, I noodle around with these:

    narrow slot size https://www.amazon.com/dp/B08CDN5PSJ?ref_=ppx_hzsearch_conn_dt_b_fed_asin_title_5
    wider top face https://www.amazon.com/dp/B0CKRJ81B5?ref_=ppx_hzsearch_conn_dt_b_fed_asin_title_1

    and the equally wide top face for these easy to interface with 2-wire serial
    https://www.amazon.com/dp/B0BKPPHYSF?ref_=ppx_hzsearch_conn_dt_b_fed_asin_title_4

    easy Spin libs for all on obex

  • in fact, I'd used larger fancy (with nice frame that mounts on large industrial enclosure) Nextion displays for Human Machine Interface (HMI) on jobs where I saw others used as well - well.. more of a science lab control system. those displays seem to be bespoke for the purpose of the machine you're creating for the customer, not a generic fiddle with the PLC type of thing.

  • MicksterMickster Posts: 2,795
    edited 2025-06-22 14:55

    This is a question that I have asked repeatedly but have never received a response; arguably, the most powerful and ubiquitous HMI is in your pocket.

    By far, the #1 failure is the HMI because it is subject to physical abuse.

    If your display fails, production grinds to a halt. Why not incorporate a Bluetooth link and talk to the device via any mobile device?

    More than 10 years in a grueling environment. Covered in grime and metal shavings. Responds like it was new.
    If it should fail, the customer has the same app on his phone until he procures a new Android tablet. It's only a Samsung Galaxy.

    The next machine over has a Siemens "industrial HMI". Many of the buttons are dead and the joystick mouse emulator is dead and so (what you'll see on every plant floor) a standard PC keyboard and mouse have been plugged in the back so they can at least use it.

    It's nuts. I've been using Android tablets since 2012 and they just run and run.

  • refaQtorrefaQtor Posts: 159
    edited 2025-06-22 15:29

    @Mickster said:
    is in your pocket.

    not in my pocket.

    I used to think that ubiquitous bluetooth touchpad was a brilliant solution and built and bought with that in mind. I don't anymore. (looking at a pile of, essentially, bricked Android tablets/phones with lost passwords or no google account) It seemed cool back in the day to "sideload" stuff, but too many hurdles now, I simply won't tolerate, any longer, the shiifting sands of some unrelated platform gatekeeping my delivery.

  • MicksterMickster Posts: 2,795

    Scenario:

    A 24/7 production line goes down at 1am Sunday.

    I am up and running within minutes. Nobody keeps spares.

    How much time would you need to get a new Nextion display and install it.

    Engineers tend to ignore these catastrophic events....it's someone else's problem.

  • MicksterMickster Posts: 2,795

    Bricked Android device?

    Never been a problem. Factory reset is always possible but if that wasn't happening, who cares?
    You can always find another. Pair the Bluetooth and you're back in business.

  • RaymanRayman Posts: 15,358

    For the particular application being worked on now, the display is just meant to be a simple status display. It is behind a piece of clear plastic, so not easily touched.
    And, it is normally encased in a big metal box, so not really for HMI use...

    Do want to add an HMI though, if can. The Nextion is nice because only need 2 pins to implement. Thinking about making a box for a Nextion display with RJ45 input, so can use RJ45 feedthrough on main box to connect to it.

    But, that might be overkill because already have Omron lighted pushbutton control, USB serial control, and soon network control.
    On the other hand, overkill is fine with me :)

  • MicksterMickster Posts: 2,795

    Well pardon the arrogance but I'm all about Occam's Razor.
    I see absolutely no need for bespoke user interfaces.

    P2 resources are precious
    Users are accustomed to phone quality GUIs

    There was a cool concept "Simblee" where you had a host app and all that you needed to do was be in close proximity to the device of interest and the appropriate GUI would appear on your device.
    Sadly, it faded away.

  • MicksterMickster Posts: 2,795

    Sorry to keep harping on about this but you build a PLC. You believe it's going to be deployed where someone can actually see it?
    No, machine builders put control panels wherever it suits them.

    It's like my DIN rail argument; those who design and implement this stuff are the ones who never end up as the sucker who actually has to work on this stuff, on a ladder, flashlight between your teeth.
    We can all design cute stuff but go try working on the installation.

  • Some comments about MODBUS:

    • I've recently implemented a MODBUS master for the P1. Because I have very little resources left in my P1 CNC boards the implementation is somehow odd. A small ASM procedure scans a buffer and sends commands to slaves, waits for the responses and writes them to the buffer. Unfortunatelly, it's not very useful to anyone else. But it shows that the basic task is relatively simple.
    • Forget the "official" documentation. It is overcomplicated because they need to address every application and all possible cases. Usually, only supporting function codes 03 (read multiple registers) and 10 (write multiple registers) is all you need. You can find documentation abou the MODBUS protocol in manuals of VFDs and servo controllers that are much easier to understand. I like the Yaskawa GA500 technical manual, for example. It explains everything, even the CRC algorithm.
    • I'll soon implement a MODBUS slave for the P2. It will control the power electronics for a medical device. The GUI (with the MODBUS master) will be some sort of tablet PC.
  • RaymanRayman Posts: 15,358
    edited 2025-06-24 10:47

    @ManAtWork posted the beginnings of a modbus RTU slave in Spin2 section here. Seems to be working with pc scanners..

    It’s actually a fairly simple thing. Am starting to like it.

    And, looks straightforward to covert to TCP…

  • MicksterMickster Posts: 2,795

    With respect. This is retarded.

    Why did Chip Gracey come up with the Propeller concept? He had a vision.

    The same should apply across industry but no, you all want to embrace the old Smile.

    All the serial bus architectures are Smile.
    A total abomination but all you do is toe the line.

    We need a revolution.

    You guys have no vision/imagination.

    Why is a bus even visible? It should be no different to dealing with a local parallel port.

    Question: How many machines running in the world, using incremental encoders?There is no error correction in this pulse train. Signals running parallel with noise generating PWM. And then we get "ooo, ooo, we need CRC for our serial comm's, checksum is not enough."

    Just take a look at the Modbus protocol and explain to me why it needs to be so ridiculously complicated.

  • RaymanRayman Posts: 15,358
    edited 2025-06-27 20:45

    @Mickster Modbus complicated? Seems super simple to me, at least after a bit of study. I'm not really sure it could get any simpler...

    But, I'm only implementing a small subset of the commands. Thinking that only 4 or 5 are really needed. Modbus scanners mostly only use the first four commands. That's probably enough for most use cases.

  • JonnyMacJonnyMac Posts: 9,375
    edited 2025-06-27 21:22

    Modbus complicated? Seems super simple to me, at least after a bit of study. I'm not really sure it could get any simpler...

    I'm with you on this, Ray. Yeah, it has oddities like some values being Big Endian and others Little Endian, but as you point out, it's well documented which means that answers are easy to come by, especially when using an AI engine to assist. Not that the AI's are perfect. Last night I got a demo response message for Read Coils that I knew to be wrong so I challenged the AI and it was corrected.

    I have an experiment running that works with all "standard" messages -- I just grabbed what was handy on my desk to create opportunities to test messages the various MODBUS messages.

    This is my rules table:

       $01  R_COILS    00001..00002    Read output state(s) of P56..P57 LEDs
    
       $02  R_INPUTS   10001..10004    Read 1-4 buttons on P40..P43
    
       $03  R_HREGS    40001           Read APA102c colors (must read 3)
                       40011           Read RTC registers  (must read 4)
    
       $04  R_IREGS    30001..30003    qty 1 : Read tC, tF, or RH from DHT11
                       30001           qty 2 : Read tC and RH
                       30002           qty 2 : Read tF and RH
    
       $05  W_COIL     00001..00002    Write output state of P56 or P57
    
       $06  W_REG      40001..40003    Write R, G, or B for APA102c
                       40011..40014    Write secs, mins, hrs, or day to soft RTC
    
       $0F  W_COILS    00001..00002    Write states of P56..P57                                      
    
       $10  W_REGS     40001           Write APA102c colors (must write 3)    
                       40011           Write RTC registers  (must write 4)  
    

    I'm assuming that the vendor (me) can make a rule like "You must write all three APA102c colors if you're using W_REGS for the pixel."

  • RaymanRayman Posts: 15,358

    @JonnyMac So, the translation from the internal zero based address to whatever Modicon or whoever wants to relabel it is something that am going to try to ignore.
    See that they want to call it like 40001 to 400011 or whatever, but going to try just using like 0..10 and see how far one can get like that.

  • RaymanRayman Posts: 15,358

    Was just thinking about calling this subset with only instructions 1..6 and only 0 based addresses as "Modbus Lite". But, seems people have already thought of that. At least, AI in browser thinks so...

  • MicksterMickster Posts: 2,795

    It's retarded
    Pofibus is retarded
    CAN-bus and EtherCAT, don't get me started.
    DeviceNET, totally retarded.

    I'm from the year 2025 and we don't tolerate this shite anymore.

    This mentality is perfectly described in The Emperor's New Clothes.

  • JonnyMacJonnyMac Posts: 9,375
    edited 2025-06-28 00:15

    @JonnyMac So, the translation from the internal zero based address to whatever Modicon or whoever wants to relabel it is something that am going to try to ignore.

    Agreed. I made that table just to have "standard" documentation, but in practice I use the 0-based offset.

    This was the first bit of code I got working. The read_inputs() method is the handler for the R_INPUTS command; it uses the starting offset to determine which specific handler code to call, or returns an exception response for an invalid offset.

    pub read_inputs() | ofs                                         ' MODBUS command 02 (R_INPUTS)
    
    '' Read the state of disrete inputs
    
      if (rxbuf[0] == BROADCAST)                                    ' illegal address
        return                                                      '  ignore
    
      ofs := get_reg(@rxbuf, 2)                                     ' get starting offset
    
      case ofs
        0..3  : read_buttons(ofs)
        other : exception_response(EC_ADDR)
    
    
    pri read_buttons(ofs) | count, last, btns, crc
    
      count := get_reg(@rxbuf, 4)
    
      ifnot(in_range(count, 1, 4))                                  ' validate # of buttons
        exception_response(EC_VALUE)
        return
    
      last := ofs + count - 1
    
      ifnot(in_range(last, 0, 3))                                   ' validate range
        exception_response(EC_VALUE)
        return
    
      btns := pinread((BTN_0+ofs) addpins (count-1) )               ' read z-aligned inputs
    
      txbuf[0] := myaddr
      txbuf[1] := R_INPUTS
      txbuf[2] := 1
      txbuf[3] := btns
    
      crc := calc_crc(@txbuf, 4)
    
      bytemove(@txbuf[4], @crc, 2)                                  ' add crc (Little Endian)
    
      send_msg(6)                                                   ' reply to master
      show_reply(6)
    
Sign In or Register to comment.