It looks like the maslow PCB used to have 4 motor control ports. Are the ones being shipped with this new batch down to 3 motor controller ports? I was hoping to experiment with using the 4th port to control a bottom looped chain with a spring retracting cable to pull down/sideways on the sled where the left right component would be controller by the 4th motor port. Is that no longer possible?
The beta PCBs had signal traces and connectors for all four motor control sections. Newer boards don’t have signal traces to some of the control pins of the unused section. I’d offer to send you my beta board, but the magic smoke escaped in a late night session many months ago…
Are there other changes to the board since the beta that are needed? Or would the beta board be compatible? I could put together a board with a schematic, or rebuild an old beta if needed.
It may not be worth exploring this option, but from what I’ve been reading, it could possibly really help accuracy in areas, and possibly speed of cut potential as well.
I’ve been thinking about tension control also and if that might be beneficial. So that the sled weight could be reduced and control of the tension on the new connection to the sled could allow for more control/testing as well. Of course, it could be getting good enough there is no real benefit. I need my maslow parts to be able to even have a reasonably educated guess.
The real issue was that the Mega only has six interrupt driven pins and we use two to read the pulses from each encoder so we’re using all of them.
Using different pins would be possible, but having hardware interrupts makes it very unlikely that any pulses could be missed. I didn’t want to offer 4th motor that I wasn’t sure wouldn’t drift over time. Not to say that it would, I haven’t tested, but that’s why the 4th plug isn’t on the board right now.
Thank you for the information. Sounds like that idea is off the table then at the moment at least. If you think it is worth experimenting with I would be happy to do so manually controlling the bottom for the time being, but I’m beginning to doubt that it makes sense to do so if there is no option or interest to create an option to do so.
I think you would be ahead of the game by looking for a way to implement your idea as a separate add-on, at least in the first stages. That would separate your project from ongoing development of the Maslow firmware (voice of experience - keeping a development branch current can be like herding cats).
Think about a separate controller for the new motor, maybe one of the very inexpensive Arduino Uno motor controller kits. The Mega currently sends position information on a regular basis in a clear format to GC. The Maslow Mega board could echo it’s present location out an AUX pin to inform the Uno where the sled is, and the Uno code could make its adjustments based on that information. If the Uno operated receive-only, it could ‘listen in’ to the communication that the Mega sends to GC by connecting to the Mega TX line, D1 (be careful not to interfere with the data flow, though).
Edit - by ‘listening in’, your board could run with any version of Maslow firmware without modification…
@blurfl, that’s a great idea. I was having a similar thought about a separate controller, but without some experience with the setup didn’t know how the integration would take place best. I like that idea, very sound.
Based on your experience, do you think it would be a worthwhile experiment/project? I’ve done very little coding in a long time, and have very limited microprocessor coding experience. Not sure I’d have the time to work on this project solo without some collaboration, especially on the software front at this time. It makes great sense in my head, but I’m still probably getting way ahead of myself.
One more option would be to use a second marlow shield and arduino. Spare parts and more motor drivers if needed later. I’d use a standard motor driver for the bottom as well.
Yes, and it could start simply and cheaply with some pulleys and cord to test concepts.
I’m thinking of a ‘two-motion’ setup with a horizontal traveler that moves across the bottom as a scalar of the X position, and a vertical element/cable that applies tension proportional to the Y position (more ‘tug’ needed when Y is negative, very little when X is near zero and Y is very positive). Testing to come up with rough values/formulae could be done statically with a mock-up like that.
Testing for a ‘single-motion’ setup would work the same way, looking for a mechanism to apply a controlled force in the appropriate direction.
If the concept can work with a mock-up, turning that into code and hardware would be a separate step, a ‘simple matter of programming’ (I had a manager that talked like that, may his… whatever). I’ve been looking at brushless motor control/encoder setups, and using a second Mega/Maslow board and a pair of Maslow motors isn’t too bad an idea. Probably could use smaller motors, and there are lots of eyes in the forum to spot alternatives. Maslovians are a resourceful and helpful lot, see the many threads with hundreds of posts.
Yes, this! 012345678
I think two motion would be ideal. For a simple test, I was thinking of just putting a pulley on the horizontal portion fixed that moves left to right at the bottom. A cable could go to the bottom of the sled, down to that pulley, and up to a temporary pully in the ceiling for testing sake. Then whatever weight wanted could be put on that so there would be a relatively constant pull on the pulley. Bungee cord from the bottom would mean a lot of change in tension, and specifically where we would not want it (near the top middle) and I think consistent pressure would be better to start testing.
That would be a single motion to start, but it would show if the project would have merit.
I’ve seen a discussion in the past of 4 motors with a constant pull. The problem is, and I believe you are already addressing it, if say Motor A is pulling the sled and Motor B is tensing against Motor A. They both have to move at the same time in opposite but complementary directions or bad things are going ot happen, the way around that is to design elasticity into the mix. However depending on the design and the timing it may have a short lifespan.
I agree, coordinating that without elasticity would be trying at best and add a lot of complexity. What I am proposing is a lot simpler, and in essence is just adding a bit of needed directionality to gravity in the appropriate vector when nearing the sides of the work space to improve accuracy in those areas. That consistent tension could potentially allow cutting speeds to increase somewhat as well.
I’m curious about your statement of design and timing making it short lived. Is there something going on I am not aware of making this a moot point? Or what are you saying more specifically.
Thank you for the feedback!
The life of all elastics is limited to number of repetitions and aging. That can be number of operations or time or normally both. Basically they are plastics, all plastic has a shelf life, in this case rubber will cure. It’s elasticity will fail with friction and time as the cure becomes oxidation the damage will become exponential. It’s like when you grab a rotted rubber band thinking it’s new. Reality is swift.
haha, I’m doing too many things at once. I thought you were referring to this potential project having a short lifespan depending on the design of it and when it was done.
I agree, using elastics is not ideal. I have the same concern for the elastics taking up the slack chain. I would definitely wish to only use them for experimentation at best. My idea of a weight and pulley for testing already rids the use of elastics.
For your implementation I would redesign the current elastics with dual sets of half strength so if 1 set fails there is something still in place.
In a unrelated elastics story, I once read of a guy that made his own bungie jumping cord by duct taping smaller cords together. He was following the foot steps of others. However he made a 300 ft cord to jump off a 250 ft high bridge, results we catastrophic.
you actually don’t want to have them move equal and opposite, because if you
aren’t along an X connecting the motors, you need to move different amounts on
the top and the bottom depending on where you are on the workspace.
I think I should sketch up a quick drawing on what I’m thinking of doing when I have a few minutes to make sure I have explained myself well.
What about a straightedge parallel bar concept? cables and pulleys would keep the systems parallel as the name implies. I had a drafting board like this back in the day.
mine had the pulleys attached to the horizontal bar and were fixed on the corners but this is the same idea
A while ago, someone mentioned a system like this. You should look at http://corexy.com/.