Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    Ability to store and process data?

    Scheduled Pinned Locked Moved
    General Discussion
    4
    11
    609
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • hekiundefined
      heki
      last edited by

      Hello,

      I have a few questions on the capability of Duet Wifi 3 board!

      Right now, I'm trying to:

      1. control a 3D printer with it using a pre-computed set of X, Y, Z, E commands
      2. get data from accelerometers which are attached on the printer.

      Here, the two tasks will need to be synced at a fixed frequency and also will need to be simultaneous, which I know is possible with the Duet Wifi. My question is, is it also able to store data within a certain timeframe after a command has been sent, AND process the data (e.g., plot the data ) while send/read tasks are still in progress? If so, how much storing and processing can be done?

      Sorry if it's a basic question... I've been looking at the datasheet but I'm not sure how to find the information I'm looking for.

      Thank you so much!

      o_lampeundefined chrishammundefined T3P3Tonyundefined 3 Replies Last reply Reply Quote 0
      • o_lampeundefined
        o_lampe @heki
        last edited by

        @heki You can poll any available data from the object model and store it on SD-card. (not sure about accelerometer data)
        Processing or plotting will happen on the PanelDue or DWC.

        hekiundefined 1 Reply Last reply Reply Quote 0
        • chrishammundefined
          chrishamm administrators @heki
          last edited by

          @heki It sounds like you need real-time control, so you'd probably have to change the firmware to achieve that. RRF already supports data collection of accelerometers (see M955 and M956) but the received data is only written to CSV files and not (yet) exposed via the object model.

          Duet software engineer

          hekiundefined 1 Reply Last reply Reply Quote 0
          • T3P3Tonyundefined
            T3P3Tony administrators @heki
            last edited by

            @heki is this data collection phase supposed to occure during a set of tests moves or during every print?

            The quickest way to do this would be to connect the accelerometer to an SBC (Raspberry PI) connected to the Duet in SBC mode and then write a script on the pi that grabbed the accelerometer data, the position from the Duet, and then stored it. The control commands could also be sent from this script, or they could be generated in advance.

            www.duet3d.com

            hekiundefined 1 Reply Last reply Reply Quote 0
            • hekiundefined
              heki @T3P3Tony
              last edited by

              @t3p3tony Thank you so much for your reply. So actually we've considered using RPi but the thing is that our motion command data and accelerometer data will need be able to be aligned so that some input/output relationship can be computed (and yes, this data collection only occurs during a set of test moves, not for every print). Using RPi to do this, it may be a little bit hard because there is no absolute timestamps on the data/command to align.. or is there?

              The ideal case would be if the input collection and processing can be done on the board, at same sampling frequency, so that this aligning process is smooth. But if not, do you think there's another way to align this using RPI?

              T3P3Tonyundefined 1 Reply Last reply Reply Quote 0
              • T3P3Tonyundefined
                T3P3Tony administrators @heki
                last edited by

                @heki how precisely co-ordinated do you need the correlation?

                www.duet3d.com

                hekiundefined 1 Reply Last reply Reply Quote 0
                • hekiundefined
                  heki @chrishamm
                  last edited by

                  @chrishamm Thank you so much for the reply. So to be precise, it needs the "sending command" and 'receiving data" tasks to be aligned, so that some input/output relationship of the printer dynamics can be computed (either in real time, or after some time delay). So do you mean it will be hard to do both "sending" and "receiving" in the board to compute, since the received data may not be exposed via object model, so it needs some conversion post-processing to do computation on the data afterwards?

                  o_lampeundefined 1 Reply Last reply Reply Quote 0
                  • hekiundefined
                    heki @T3P3Tony
                    last edited by

                    @t3p3tony So the timeframe onto which the input/output should be aligned is in 1 ms units, but at this moment I've yet to test how sensitive the input/output relationship will be by changing the precision of alignment..

                    T3P3Tonyundefined 1 Reply Last reply Reply Quote 0
                    • hekiundefined
                      heki @o_lampe
                      last edited by

                      @o_lampe I see, thank you so much.

                      1 Reply Last reply Reply Quote 0
                      • o_lampeundefined
                        o_lampe @heki
                        last edited by

                        @heki said in Ability to store and process data?:

                        So do you mean it will be hard to do both "sending" and "receiving" in the board to compute, since the received data may not be exposed via object model,

                        I wouldn't connect the accelerometer to the Duet, but let the RasPi read out the data directly. There are Arduino libraries for the accel-sensor, they can be rewritten in python, for sure.

                        BTW: the sample rate of the sensor is pretty low (some kHz?) . I'd rather use interrupts to control the poll-rate instead of fixed intervalls.
                        That optimizes the amount of processable data.

                        1 Reply Last reply Reply Quote 0
                        • T3P3Tonyundefined
                          T3P3Tony administrators @heki
                          last edited by T3P3Tony

                          @heki so in rough outline the data flow is:

                          • read from input (SD card, USB, Network, UART etc)
                          • process (buffer, plan, step generation)
                          • step output to motors

                          The difference in SBC mode for commands coming from the SBC is the input stage can be intercepted and logged/used in some way. Other than that the Duet is doing the processing and step generation.

                          What exactly do you need to collect?

                          • Whole moves?
                          • individual steps?
                          • something in between?

                          You may be able to get what you need but running a move, capturing the accelerometer data as we do already and then processing it after the fact. then running another move. After all you know the move you commanded, and you know the accelerometer response.

                          www.duet3d.com

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post
                          Unless otherwise noted, all forum content is licensed under CC-BY-SA