Functional Test - ADXL345 status information

[nefelim4ag]

@mykepredko

Now, when I run the statement, I get a lot more than the few lines you posted above.

Of course, you will see the general Klipper log, and it would be different from mine.
There is no reason to post my infinite log output here, even more, it does not make sense, because the output will depend on the actual config, connected peripherals & etc.

@mykepredko

Ctrl-C doesn’t stop the torrent of data - I have to shutdown and restart (which is something I don’t want to do on the manufacturing floor).

& means run in the background.
You have seen in your console the

@mykepredko

[1] 4045

Which means there is 1 process in the background, and the last forked process has a pid of 4045.
So, you can kill it, kill -p 4045.

~ sleep 15 &
[1] 4878
~ sleep 15 &
[2] 4887
~ sleep 15 &
[3] 4896
~ sleep 15 &
[4] 4905

That is the reason why I suggested you use multiple consoles to grasp the idea.
Because that allows not to use &.

@mykepredko

Along with all that, when I look at Mainsail, I get:

There should be OR, you either run from the console, control from the console & etc, or you run with Moonraker, web UI & etc.

Anyway, there should be one instance of the klippy (klipper host), which would in the end control the MCUs of your testing boards.

I would suggest that you check the @Sineos suggestion and script examples.

(Functional Test - ADXL345 status information - #6 by Sineos - or you could really try using of existing klipper console, alongside running moonraker & etc, instead of doing everything as I suggested in a headless manner (without other control software))

FWIW, I more or less understand what you’re trying to achieve (test the board, by the klipper for the klipper).

So, the whole architecture of abstractions looks like:

1. WebUI (your browser) (REST API) → 2. Moonraker (JSON RPC) → 3. Klippy (Klipper Protocol) → 4. Klipper’s MCU.

So, there are 4 levels of automation and working with abstractions.

1. What you do now: macros/selenium/meatbag (human). Someone or something interacts with WebUI, which does all the requests and checks the output.
2. Do the web requests to the moonraker. Which will forward g-code to the Klippy, check the statuses, output & etc.
3. Write Python/Shell/Expect (anything), which will talk to the klipper. Either by console or by json rpc. I suggested console, it is much more intuitive to run G-code and check the output.
4. Run low level commands directly to the MCU, initialize, configure mcu, do steps, spi transfer & etc.

So, the 3rd variant, which I initially showed and suggested, works in the same way as OctoPrint controlling the Klipper. Something feeds G-code, and someone or something checks the console output.

But in reality, there are at least 4 levels where you can automate what you want.
That will all depends on what things you are familiar with, and what will be simpler for you.

I feel like I’ve complicated your life with my little/initial suggestion.

Hope that clarify something.

[mykepredko]

Heya,

Thanx for the lengthy reply - it’s appreciated.

A few comments back and then I’ll give a reply to @Sineos’s post and an update as to what’s working (with one question).

@nefelim4ag

@mykepredko

[1] 4045

Which means there is 1 process in the background, and the last forked process has a pid of 4045.

Grrr. I should have realized that from work I did a decade or so ago. Thanx for pointing that out.

@nefelim4ag

So, there are 4 levels of automation and working with abstractions.

1. What you do now: macros/selenium/meatbag (human). Someone or something interacts with WebUI, which does all the requests and checks the output.
2. Do the web requests to the moonraker. Which will forward g-code to the Klippy, check the statuses, output & etc.
3. Write Python/Shell/Expect (anything), which will talk to the klipper. Either by console or by json rpc. I suggested console, it is much more intuitive to run G-code and check the output.
4. Run low level commands directly to the MCU, initialize, configure mcu, do steps, spi transfer & etc.

I hope I’m not insulting by saying that you’re looking at the situation as a software developer.

On the manufacturing floor, the overall test process must be:

1. As automated as possible. That means that it works with a minimally skilled operator for “Sort” (good/bad) testing. The boards will be manufactured in China where, at best, English is a second language so the number of console/GUI operations they have to execute have to be minimal - ideally the test will start when power is applied and will not require any input or observation by the Sort operator and they just have to wait for a Red/Green light for pass/fail.
   There will be a debug/failure analysis technician with higher electrical skills who better understand what’s happing on a failing board but still needs simple software tools to work with.
2. Minimize the number of off process steps as possible - there are two reasons for this with the first being to minimize cost and the second is to avoid having to put boards in different states in different locations. Along with testing the board, I have the issue of trying to figure out how to program the MCU with there being these requirements:
   → Programming the STM MCU’s Option Bytes so that DFU mode can be implemented. DFU works well when the MCU is first powered up but its operation becomes spotty so I can’t rely on it on the manufacturing floor. If I have the requirement to cycle power then that adds more process steps and makes things harder to implement. There is, however, something that I can take advantage of and that is:
   → Loading Katapult onto the MCU. What makes Katapult really nice is that, after it is loaded into the MCU, by double cycling the MCU’s reset line “quickly”, it comes up and can be used for loading a new application firmware code without power cycling. This allows me to:
   → Load Klipper into the MCU for the test operation. Today’s version of Klipper is great on the manufacturing floor, but it will probably be downlevel when the user gets the board. That means the Klipper firmware must be removed (or appear to be removed by the user when they first power up the board) which means that Katapult must be started again and
   → Four 0xFF bytes loaded into the Application Firmware area of the MCU’s Flash must be loaded. I’ve found that by making a simple four byte file of 0xff it will appear to Katapult that there isn’t any firmware loaded and it will Flash the status LED to indicate that it is ready to accept Firmware (or, the user can use DFU).
3. Keep the test apparatus as simple as possible. This is for cost as well as minimizing the required bench space on the manufacturing floor. Having multiple consoles will be problematic. With what I’m thinking about here is that along with the board, the test apparatus an HDMI monitor and USB keyboard will be required.

@nefelim4ag

I feel like I’ve complicated your life with my little/initial suggestion.

No, not at all. It was not at the level I was expecting and how it worked wasn’t obvious.

I do appreciate your comments.

[mykepredko]

@Sineos

I’d just install Klipper as you would as a user. Fiddling around with the command line approach doesn’t add any value in this context and only introduces additional complexities.

Agreed and I want things to work as close to an actual Klipper environment to ensure things are working properly.

@Sineos

For a similar task (non-Klipper), I wrote a Bash script a while back that I quickly adapted for Klipper. I know Python folks might shake their heads and smile mildly, but I’m just a script kiddie, and if I need something quickly, I feel most comfortable with shell scripting.
:

Bash Scripts are great - I wouldn’t be critical of what I see in the attached one.

Can I ask why did you create a coprocess for running the requests? I can’t see any advantage in doing that.

[mykepredko]

Just an update here.

First off, I updated the design of my rPi Hat so that I can also control the RESET and BOOT0 Pins of the Board Under Test (the red text is notes for me if I ever want to get more PCBs fabbed):

It connects to the Board Under Test like my hand built one but has a six pin header that connects to a ribbon cable which goes to the (BTT standard) SWD port:

The LED is for a feature that will be on the board when I respin it.

To access the MCU using the rPI Hat, I use some pretty basic python applications: newHat2_Python.zip (1.5 KB)

The application names should be pretty self-evident (ie “enableKatapult.py” enables Katapult by cycling the RESET pin quickly).

I have Bash scripts for checking and resetting Klipper are similarly simple: newHat2_BashScripts.zip (1.4 KB)

With the new rPi hat and simple scripts, I can control the MCU on the Board Under Test’s mode BUT there doesn’t seem to be a consistent way of restarting Klipper.

If I enable Katapult in the Board Under Test’s MCU, check that it’s operational and then cycle RESET to return execution to the installed Klipper Firmware, it takes a varying number of FIRMWARE_RESTART commands to get Klipper back up.

For this example, it took two FIRMWARE_RESTARTS to get Klipper back up and running:

biqu@cm4-kgp79:~ $ python enableKatapult.py
biqu@cm4-kgp79:~ $ ls /dev/serial/by-id
usb-katapult_stm32g0b1xx_190052001050505933383420-if00
biqu@cm4-kgp79:~ $ python cycleRESET.py
biqu@cm4-kgp79:~ $ ./sineosREADY.sh
// Klipper state: Shutdown
// Lost communication with MCU 'mcu'
// Once the underlying issue is corrected, use the
// "FIRMWARE_RESTART" command to reset the firmware, reload the
// config, and restart the host software.
// Printer is shutdown
// Klipper state: Not ready
!! Lost communication with MCU 'mcu'
ok
<== Klipper Not Running - Execute "FIRMWARE_RESTART"
biqu@cm4-kgp79:~ $ ./sineosFIRMWARE_RESTART.sh
ok
// Klipper state: Disconnect
<== Klipper Not Running
biqu@cm4-kgp79:~ $ ./sineosREADY.sh
// Failed automated reset of MCU 'toolhead'
// Once the underlying issue is corrected, use the
// "FIRMWARE_RESTART" command to reset the firmware, reload the
// config, and restart the host software.
// Error configuring printer
!! Failed automated reset of MCU 'toolhead'
// Failed automated reset of MCU 'toolhead'
// Once the underlying issue is corrected, use the
// "FIRMWARE_RESTART" command to reset the firmware, reload the
// config, and restart the host software.
// Error configuring printer
!! Failed automated reset of MCU 'toolhead'
// Failed automated reset of MCU 'toolhead'
// Once the underlying issue is corrected, use the
// "FIRMWARE_RESTART" command to reset the firmware, reload the
// config, and restart the host software.
// Error configuring printer
!! Failed automated reset of MCU 'toolhead'
// Failed automated reset of MCU 'toolhead'
// Once the underlying issue is corrected, use the
// "FIRMWARE_RESTART" command to reset the firmware, reload the
// config, and restart the host software.
// Error configuring printer
!! Failed automated reset of MCU 'toolhead'
// Failed automated reset of MCU 'toolhead'
// Once the underlying issue is corrected, use the
// "FIRMWARE_RESTART" command to reset the firmware, reload the
// config, and restart the host software.
// Error configuring printer
!! Failed automated reset of MCU 'toolhead'
// Failed automated reset of MCU 'toolhead'
// Once the underlying issue is corrected, use the
// "FIRMWARE_RESTART" command to reset the firmware, reload the
// config, and restart the host software.
// Error configuring printer
// Klipper state: Not ready
!! Failed automated reset of MCU 'toolhead'
ok
<== Klipper Not Running - Execute "FIRMWARE_RESTART"
biqu@cm4-kgp79:~ $ ./sineosFIRMWARE_RESTART.sh
ok
// Klipper state: Disconnect
<== Klipper Not Running
biqu@cm4-kgp79:~ $ ./sineosREADY.sh
// Klipper state: Ready
// SETINDICATOR: ok
// SETINDICATOR: ok
// SETINDICATOR: ok
// SETINDICATOR: ok
// SETINDICATOR: ok
// Klipper state: Ready
ok
<== Klipper Up and Running
biqu@cm4-kgp79:~ $

I can loop the READY & FIRMWARE_RESTART commands to Klipper as many times as required but if there were a defined delay or other command to get things running again would be appreciated.

Thanx!

[Sineos]

@mykepredko

Can I ask why did you create a coprocess for running the requests?

This was initially used for some experiments with my central heating control. The advantage of the coproc is that it creates a pipe between the cat and the script that remains open. My central heating system would send an EOT, making it easier to handle rather than terminating the cat after an arbitrary timeout.

You can see the effect on multiple successive commands as the returns are no longer ordered. AFAIK, in the Klipper communication, there is no EOT indication.

Nice work overall with your hat and the approach.
Regarding the RESTART issue, I unfortunately have no good ideas. Does it behave differently when, for example, reset by the hat and then controlled by the web UI?

[mykepredko]

Thanx for the kind words. I’m pleased that it’s coming together - it look simple but there was a lot of experimenting that got me here.

@Sineos

Regarding the RESTART issue, I unfortunately have no good ideas. Does it behave differently when, for example, reset by the hat and then controlled by the web UI?

No. I’ve tried that. It always takes at least two FIRMWARE_RESTART commands, either from the command line via Bash script, clicking the button in Mainsail or typing in FIRMWARE_RESTART to the console window.

Waiting for some length of time doesn’t change anything either.