4 ms·

Yep. We use smart PLCs (programmable logic controllers - basically an Intel Atom powered realtime platform with modular high-speed analogue/digital I/O) for a

Yep. We use smart PLCs (programmable logic controllers - basically an Intel Atom powered realtime platform with modular high-speed analogue/digital I/O) for a lot of our projects. For one project, we were planning on deploying a cheap PLC plus a thermocouple module and some SPI modules. Because of availability, that turned into buying thermocouple and SPI interface chips ourselves, and designing a custom PCB to interface those to a Raspberry Pi. And now of course Raspberry Pis are impossible to get, so while we managed to get hold of enough for the first run of deployments, we don't have any more of them - we even had to ship our tester Pi! It's a real scramble, and we've definitely lost a bunch of money on that project.

rasz 4y ago
Do you really need multicore linux computer with gigabyte of ram to send temperature over the network?
- vorpalhex 4y ago
  That depends on how fast you're sending it, how you are sending it, how precise it is, and if edge calculations have to be run, and calibration workloads.
  - rasz 4y ago
    All valid points in 1985. Nowadays smallest cheapest microcontroller has more processing power than fastest desktop from 1995.
    - vorpalhex 4y ago
      And in the last 30+ years do you think that maybe some of what we do with temperature data has changed? Or how we interact with a network? Or the data that sensors can produce? If you think you can answer parents problems without even knowing the problem space, you're behaving foolishly.
      - camtarn 4y ago
        Hey, it's alright - rasz just asked a question, and it was a fair one :)
        vorpalhex 4y ago
        There's asking a question to learn and there's indicating that someone did something the wrong way without understanding the problem space. Understand the problem, then propose solutions. Anything else is ass backwards.
      - rasz 4y ago
        OP described remote temperature sensor for a PLC. What you might want to do with data might changed, but how we gather it only got optimized down to specialized controller chips. Amplification, compensation, linearization - all taken care of by dedicated interface chips, something like AD849x, MAX6675/MAX31855 or ADS1118. There is nothing left to do at the remote end that cant be done further down the line. Measurement is pretty much Push Button, Receive Bacon to the point you can build your own soldering station with arduino, one of those chips, mosfet and a display module in 100 lines of code.
  - com2kid 4y ago
    When it comes to sensors and latency, you can use a 200mhz cortex m3 with a bespoke runtime you write in a couple weeks, or you can throw a real OS on top of multiple Ghz and cores in order to make up for the overhead of having a real OS. SRAM running at 200mhz with 1 cycle latency can perform what looks like miracles when placed side by side with DRAM running at LOLWTF Ghz that is stuck behind 100 cycles of delay talking to the CPU that first tries to work its way through multiple steps of onboard cache and lookup buffers and all sorts of fun things. Embedded controls can do stupid amazing things with very little resources because all of a sudden you have removed a huge constant delay from all memory accesses. Throughput, however, they don't do so well on throughput. :-D
    - jjoonathan 4y ago
      Yep. DRAM latency is no joke -- ask your fancy 32 core 5GHz super-duper-scaler CPU to chase a linked list and it turns back into one of those old beige boxes with the turbo button, but with the turbo button not pressed!
      - com2kid 4y ago
        Linked lists and SRAM are so much fun.... All sorts of data structures that are cache and dram unfriendly are a-ok in embedded land.
      - gugagore 4y ago
        If I remember correctly, pressing the turbo button actually slowed down the CPU clock.
      - freemint 4y ago
        Linked lists are fine. Trees with tagged pointers less so.
- camtarn 4y ago
  Yep, that's a fair point: both the Raspberry Pis and the smart PLCs were indeed absolutely overkill for the project. However, they're what we know best, and minimising development time for a small prototype multi-site deployment was more of a concern than using expensive-ish hardware. For production, obviously we'd move to something less ridiculous.
- willis936 4y ago
  No and you don't want it either. In lieu of reliable hardware (PLCs), it is what is needed for virtual PLCs.

rasz 4y ago

Do you really need multicore linux computer with gigabyte of ram to send temperature over the network?

vorpalhex 4y ago
That depends on how fast you're sending it, how you are sending it, how precise it is, and if edge calculations have to be run, and calibration workloads.
- rasz 4y ago
  All valid points in 1985. Nowadays smallest cheapest microcontroller has more processing power than fastest desktop from 1995.
  - vorpalhex 4y ago
    And in the last 30+ years do you think that maybe some of what we do with temperature data has changed? Or how we interact with a network? Or the data that sensors can produce? If you think you can answer parents problems without even knowing the problem space, you're behaving foolishly.
    - camtarn 4y ago
      Hey, it's alright - rasz just asked a question, and it was a fair one :)
      - vorpalhex 4y ago
        There's asking a question to learn and there's indicating that someone did something the wrong way without understanding the problem space. Understand the problem, then propose solutions. Anything else is ass backwards.
    - rasz 4y ago
      OP described remote temperature sensor for a PLC. What you might want to do with data might changed, but how we gather it only got optimized down to specialized controller chips. Amplification, compensation, linearization - all taken care of by dedicated interface chips, something like AD849x, MAX6675/MAX31855 or ADS1118. There is nothing left to do at the remote end that cant be done further down the line. Measurement is pretty much Push Button, Receive Bacon to the point you can build your own soldering station with arduino, one of those chips, mosfet and a display module in 100 lines of code.
- com2kid 4y ago
  When it comes to sensors and latency, you can use a 200mhz cortex m3 with a bespoke runtime you write in a couple weeks, or you can throw a real OS on top of multiple Ghz and cores in order to make up for the overhead of having a real OS. SRAM running at 200mhz with 1 cycle latency can perform what looks like miracles when placed side by side with DRAM running at LOLWTF Ghz that is stuck behind 100 cycles of delay talking to the CPU that first tries to work its way through multiple steps of onboard cache and lookup buffers and all sorts of fun things. Embedded controls can do stupid amazing things with very little resources because all of a sudden you have removed a huge constant delay from all memory accesses. Throughput, however, they don't do so well on throughput. :-D
  - jjoonathan 4y ago
    Yep. DRAM latency is no joke -- ask your fancy 32 core 5GHz super-duper-scaler CPU to chase a linked list and it turns back into one of those old beige boxes with the turbo button, but with the turbo button not pressed!
    - com2kid 4y ago
      Linked lists and SRAM are so much fun.... All sorts of data structures that are cache and dram unfriendly are a-ok in embedded land.
    - gugagore 4y ago
      If I remember correctly, pressing the turbo button actually slowed down the CPU clock.
    - freemint 4y ago
      Linked lists are fine. Trees with tagged pointers less so.
camtarn 4y ago
Yep, that's a fair point: both the Raspberry Pis and the smart PLCs were indeed absolutely overkill for the project. However, they're what we know best, and minimising development time for a small prototype multi-site deployment was more of a concern than using expensive-ish hardware. For production, obviously we'd move to something less ridiculous.
willis936 4y ago
No and you don't want it either. In lieu of reliable hardware (PLCs), it is what is needed for virtual PLCs.