[Matt G]

I will post up an apk tomorrow when I can get it compiled. It’s still a very beta version, and I’ve only tested it on my Samsung devices.

Will post a link here when I get it up.

[Matt G]

So there is a configuration item that sets a timeout for the steppers to disable. The json attribute is “stepDisableSecs”.

Now if your status says it’s still running, I don’t believe the timeout would actually engage.

I also didn’t write the firmware, and the robot motion code is pretty intense. I find it easier to trace loaded into vs code, and searching for the json attribute usage to see what actually reads that, and then what would trigger the code that uses the stepper timeout.

My Android app monitors the number of operations in the queue to calculate the state of the bot. I believe that’s available in the status rest endpoint. You can see the path to all the endpoints I’ve interfaced with in this Android file.
https://github.com/grammesm/SandBot-Android/blob/master/app/src/main/java/com/alwaystinkering/sandbot/data/SandBotInterface.kt

If you monitor the “qd” attribute in the status json, you can see how many operations are queued up. If that never hits 0, I wonder if whatever pattern you are running is never ending?

• This reply was modified 4 years, 1 month ago by Matt G.

[Matt G]

Hey Kevin

The exact end stops I used are these

[Matt G]

Excellent news.

I wish everything was standardized to make stuff like this easier to track down, but glad you were able to solve the problem!

[Matt G]

Interesting that you found that out. I would start building the homing string up piece by piece. The A+5000n should be rotating an additional amount until the sensor is un-triggered.

What type of sensor do you have? It is possible that the sensor’s signal is opposite of mine, so the first big “N” is always tripped, and then the small “n” in the A+5000n is actually being hit when the sensor triggers on.

So what I would try is start here:

“FR10;A+10000N#;A=h;B=h;$”

Make sure that the bottom arm will stop as soon as the sensor is tripped in this scenario. Once verified, you can add on some more…

“FR10;A+10000N;#;A+5000n;#;A=h;B=h;$”

To verify that the lower arm the proceeds the additional steps until the sensor un-triggers.

If the first step fails – then you know that big “N” is not happening when your sensor is triggered.

To debug that further you can play around with the robot configuration for the endstop in the cncUi.html’s settings area.

			"endStop0": {
				"sensePin": "36",
				"actLvl": 0,
				"inputType": "INPUT_PULLUP"
			}

You can try changing the active level to see if your sensor’s “default” state is 0, instead of 1 like mine…

So start out small with the initial steps and build up until you get a string that works for you.

You could also try

“FR10;A+10000n#;A=h;B=h;$”

with a small “n” if the initial big “N” isn’t working in this initial test too.. Let me know how it progresses!

[Matt G]

So I can confirm that triggering the “elbow” sensor during homing of the bottom arm should not stop homing:

I have annotated this picture, that goes along with my robot configuration to show which connections go to which motor/sensor for motor A/B and sensor 0/1 alignment

• This reply was modified 4 years, 3 months ago by Matt G.

[Matt G]

So if you’re using the same homing string.. I don’t think that interrupting the upper arm sensor while the lower is homing is supposed to stop it. I’m not positive.. I’ll open my table when I have time tomorrow and check.

Can you try swapping sensor pins? Wondering if the sensor signal pins are swapped.

Also – I have never tried the home all button on cncUi.html. I always use the home command from sandUi.html – which I believe sends a g28 gcode command. So it’s possible the home all button is doing the same.

[Matt G]

If you look in the first post in this thread, there is a link to the actual firmware code that is processing the homing string.

I’m struggling to figure out how you can get into a situation where manually tripping the optical endstop works, but the arm triggereing it doesn’t.

Are you waiting until the 2nd arm starts homing before triggering the endstop manually when testing? You would need to make sure the homing is in the same state when the 2nd arm is rotating to properly test.

Another tip is you could remove the “duplicate” movements in the first portion of the homing string to keep the arms aligned. For example in my example above:

Changing
A+10000N;B-10000;#;
To
A+10000N;#;
and so on – just to be sure that A is mapped to the first arm like you expect, and you just don’t happen to be tripping A’s sensor with the B movement.

You need to make sure that in your string the A commands are moving the bottom arm. It sounds like they are since you mentioned only the top arm moves in the 2nd portion of homing.

Can you post your homing string here?

[Matt G]

I actually use rufus for my raspberry pi images, so perhaps that’s why the old pi card worked…

[Matt G]

Glad to hear it worked!

See this post to get the bot on the network…

Setting up and configuring the SandBot

[Matt G]

so I recall that in older versions of the firmware repo, I was seeing some size errors. I would try uninstalling everything (vscode etc..) and download the latest. Make sure you have a fresh clone of the firmware repo like in the video too. With everything clean, and installing the espressif32 support package through the platforim IO “platforms” option (~4:07) in above video, I have no problems compiling the firmware.

[Matt G]

The adalogger (and all other wings) are designed to mount directly on top (or below) of the huzzah32 like this

If you solder stacking pins through the huzzah32, then you can just plug the adalogger in to the top.

Stacking pins: https://amzn.to/3ePn0zS

In regards to compiling, have you followed this video exactly?
https://www.youtube.com/watch?v=LeNXUhOl0Qo

Nice on the laser cutter! That’s one tool I wish I had

[Matt G]

You need to use the adalogger featherwing. If you look at the original post http://alwaystinkering.com/2020/01/14/diy-kinetic-sand-art-table/

See the section
Micro SD Card Update (June 18, 2020)

Essentially, if you are using my pinout and config, you need to jump the CS pin on the adalogger to pin 21.

[Matt G]

Hi Geri

1. The table does not automatically home when you start it up. There is a section of the JSON config called “cmdsAtStart”, which is blank in my config. You can add “g28” to this value to home on startup. g28 is the gcode command for home.
2. The homing string is also located inside the JSON config at the key “homingSeq”. The firmware code file that processes this string is at https://github.com/robdobsn/RBotFirmware/blob/master/PlatformIO/src/RobotMotion/MotionControl/MotionHoming.cpp if you can understand c++ and how it processes that string.
3. No – you need to start a pattern after homing.
4. Once you shut the table off – if you have nothing in “cmdsAtStart” in the JSON config, the table will do nothing when you turn it back on, so you will need to re-home and re-start the pattern. Once the stepper drivers lose power, there is no way for them to know what position they are at, so you can not restart the drawing process.

[Matt G]

The latest card I got working on the bot (from the screenshots above) appears to be an old SD card I used for a linux or raspberry pi installation, so it still has a .sys file on it, so that may be another route to try with different cards.

• This reply was modified 4 years, 6 months ago by Matt G.

[Matt G]

I haven’t been able to get it to work on the few microSD cards I have laying around, so if you figure out something that works, please let me know!

[Author]

Posts