How to generate pulse at the exact rate you need... First make a loop that runs as fast as you can make it run. The first thing it does is "sleep" for a hundred or so microseconds. Then it checks the time of day and to see if it is time yet to do the next pulse. If not it fall to the end of the loop and does the slepp again. Finally it is time. So the program sets the GPIO bt "high" and then adds (say) 20 microseconds to the current time and calls the "TimeToShutOffThePulse" Then the loop checks if the system time is equal or greater than TimeToShutOffThePulse. If true it sets the GPIO pin to low. It them computers the time when the pulse needs to be high again and goes back to sleep and when finally it is time to set the pulse high it does.
The key here is that you loop must spend most of it's time sleeping but also needs to check very frequently. Actually the program might be moving three motors so it neds to track the next time to move a pulse up or down and has a table fullof things o do in the future and keep chacking if it is time yet to do the first thing on the table. If so it does it, then maybe adds one more entry to the table. BIG PROBLEM. This will work more or less and avreraged ver long periods like 0.5 secondsthe pulse rate will be good. But Linux is a multi-tasking OSand it will have to run other tasks so many pulses will get delays and the moterwill notkeep aperfectly even speed. You may not notice but it will never be perfect. How to fix this: Funny you aks this on a LinuxCNC list. LinuxCNC uses a specal real-time version of the Linux kernal and the above describbed loop runs as a real-time task. This is a new thing that normal Linux does not do. These real-time tasks run inside the Kernal and there is never any task swapping of CPU sharing to get in the way of your loop. But still it si not perfect, but likey good enough for this. 10 years ago I wrotesoftware to rrack stars in the sky using RT Linux. It worked well enough because starsreally don't move very fast. And second solution is to use a normal Linux Kernalandthen place the real-time loop inside a micro controller. THis is easier because you cn use a "stock" Linux and not have to compile and install a custom Kernal. In is also about three orders of magnitude more accurate then enven the RT version of Linux. So running that loop that continously askes "Is it time yet?" in a normal Linux process will almost work but not really well because the CPU cores are shared between many tasks. Yes you can fiddle to priorities and almost get it to work. The "good enough" solution is to run the loop as a Real-Time task under the a Real-Time version of the Linux kernal but this requires you to understand mess with Linux kernals You also need a normal user-level non-real-time task to send control parameters to the RT kernal task (this is mostly how LinuxCNC works) THe other "good enough" solution is the run the loop inside it's own small computer where theis to is operting system and no multi-tasking and the the Linux system simple passing parameters to the microcontroller. (Linux CNC can also work in this mode, the LinuxPC taking to special hardware that genertes the sulses. Almost there. Reading the encoders. This is REALLY hard to do using a Raspberry Pi. Each encoder has two pins andthe signals change fast. They can change REALLY fast on the Az and El axis if you are moving to a new target quickly. Best to use the microcontroller but you can also connect to the Pi's interrupt pins Use 6 GPIO pins are interrupts and just keep three counters. You need to look up how to handle quadrature encoders On Thu, Jul 9, 2020 at 8:30 PM R C <cjv...@gmail.com> wrote: > > On 7/9/20 6:47 PM, Chris Albertson wrote: > > OK, got it a "Dob, on a Ea, platform and the platform on an Az, El mount. > > > Yup. > > > > > Again PWM is "Pisle Width Modulation" Steppers and stepper drivers don't > > use PWM. They use what we cal "Pulse/Direction" > I didn't know that, I read the product manual, it mentioned PWM, with > some specs, I tried that, seems to kinda work.... well work as in a > okcupid profile that says "I don't like drama and games" but some how it > doesn't seem to do what expected. > > > > PWM uses a constant square wave rate like that is always between 60 Hz > and > > maybe up to 1,000 Hz. What changes is the "duty cycle" or the ratio of > > "on" to "off". But it just runs at about 60Hz. PWM uses just one wire. > > Right, and some hardware let's you pick the frequency, up front.. and > then change the duty cycles. that is what I figured. However, I saw in > the manual, the "high" side of the pulse in the duty cycle" lasts > always 2.5usec and you change the length of the cycle. To me that just > seems that you change the duty cycle, relative to the frequency... as > in the frequency is determined by how you build the cycles.. which is > what I see happening. > > > > > > Pulse/Direction uses two wires. One sends a single pulse each time the > > motor needs to move a step and the other wire is either "1" or "0" to > > indicate the direction, either backward or forward. > > correct, direction is either constantly high, or constantly low.. for > how long you want it... and that works perfectly > > > > > > With this type of system I don't think you worry about minor things like > > atmospheric refraction of structural flex. You can just run at a > constant > > rate. > > Yes .. at this point I am not worried about that. I want to make a > "mechanical" precise contraption. > > > > > > I am wondering why you selected a Raspberry Pi and not some micro > > controller. Perhaps you are planning a user interface that is complex? > > well.. sort of. I am planning on one that does the "positioning, one > that does the imagng and if needed one that does that "positioning" > > I use them because they are easy to use, run Linux, I know Linux, > hardware.. I can hook it up to a network, and see if I canhave > Stellarium" send coordinates to it at some point. It is more a "olution" > that I can build on and expand.... if I wanted to. There are very > compact solutions to use, that are cheaper, easier etc.. BUT I want > o build my own my way,. > > I built a seismograph like that, could be done easier/cheaper, but I > wanted to build an online one and do it myself ... just because I can > .. and because I think it can be done. > > I'm a researcher/scientist, I like to build things so I can figure out > how it works... > > > > > All you software needs to do is generate plusle each time the motr needs > > to step. For the motor that runs the EQ platform this step rate is > fixed > > forever. For the other two they can step at whatever rate do want. > > Yes exactly, that is what I noticed. I can move the stepper at pretty > much any desired rate/speed I want, pretty precise, and.. if it runs at > the exact right speed. that would be cool. > > BUT, I want to know how to figure out how to run it at the exact right > speed, with the exact right power, optimally, as best as I can .. and > not by trial and error and decide "yeah good enough", I want to > calculate it. > > So that is why I want to understand what the best way is , software > wise, to drive those steppers, to run those motors, algorithm wise. > > > > > > Why encoders? If the motors are proerly sized they will never skip steps > > and you can count steps to know where you are. If you put on encoders > you > > just need to encoder steps > > The encoders are just there to check, and fun to play with.. or more > seriously... > > I use the encoders similar to a prenup, hope I don't need it/them to > correct mis-steps... but it doesn't hurt to have > > > > > > > > On Thu, Jul 9, 2020 at 1:48 PM R C <cjv...@gmail.com> wrote: > > > >> there will be worm gears, and those will just gear all the axis/axes > >> down down. > >> > >> On 7/9/20 1:23 PM, Chris Albertson wrote: > >>> Telescopes are something I know a little about, What you don't tell us > >> and > >>> what matters quite a lot is the mechanical gearing. How are the > >>> motors connected to the mount? > >> there will be worm gears, and those will just gear all the axis/axes > >> down down. the 3 motors are going to be connected to a stepperdriver > >> (DM542 or so) and the stepper drivers are 'driven' by an raspberry pi > >> (mounted in the mount) and I am using a quadrature encoder on all 3, on > >> the shaft that drives the main gear on each motor. > >> > >>> If this is an equatorial mount what are there three motors? and why > care > >>> much about if declination moves smoothing as it is only for slewing to > a > >>> new target. > >> > >> It is not exactly an equatorial mount, it is an equatorial platform, > >> aligned with polaris (northern star) and it turn oposite the rotation of > >> the earth, to compensate for rotation. > >> > >> it only has one motor, because it only has to tilt to compensate for > >> rotation, at a steady speed. The telescope, with a dobsonian mount is > >> standing on top of that ... and > >> > >> it has an azimuth (rotate horizontally, with respect to the platform) > >> and and an elevation mount, to tilt the telescope. > >> > >> > >> So one motor for the platform, one for rotating it (azimuth) and one > >> motor for altitude, tilting the tube.. (the latter two are for > >> "convenience" just to point the telescope at an object and precission > >> is not "that" big a deal because once the object is in sight, those two > >> motors 'hold'. after that the plaform is tilting, to compensate for > >> rotation of the earth). > >> > >> > >>> But if this is Az, El then yes I see why three motors, You have Az, El > >> and > >>> Feild rotation and all most move smoothly and in exact synchonized > >> motion. > >>> But an equatorial drive needs only one moer to move smooth. > >> > >> Exactly.. you got the idea there. once the object is "locked in" only > >> the equatorial platform has to precisely move, without "jerking" > >> > >> > >>> As for PWM. PWM is nothing at all to do with stepper motors. You > can > >>> forget about it. Unless you decide to not use steppers. > >> > >> I am using stepperdrivers, which are running the stepper motors, and > >> the stepperdrivers use PWM to tell them what to do? > >> > >> > >>> > >>> The way to work this is to choose a gear ratio, typically a very large > >>> reduction, andchoose a step size that is literally "invisable" given > you > >>> angular resolution. Of course angular resolution depends on aperture > or > >>> maybe the pixel size and focal length if this is purly a photographic > >>> 'scope. The steps need to be smaller then 1/2 the angular resolution > >> and > >>> conservative designers might go even smaller, Hence the use of really > >> big > >>> worm/wheel reduction systems > >> > >> I already have figured out the mechanical part so that even with full > >> steps, I can still accurately move t=it and track rotation of "the > >> field" aka rotation of the earth. > >> > >> > >>> Example. (1) You have a 180 tooth gear and a 1.8 degree step size. > >> That > >>> works out to 36 arc seconds per step. This might be good enough for a > >>> small scope used in poor seeing condidtions. > >>> (2) 360 tooth gear and 1/8th microstepping now you are at roughly 2 > >>> arcseconds per step. This is much better > >> I have two 360 gear sets (for alt/azi) but they are big.. and a 60 > >> teeth gear/work set. ratio 60:1 > >> > >> (one rotation of the gear needs 60 rotations of the worm, with full > >> stepping that means 12,000 steps for > >> > >> one rotation of the shaft that turns the platform. and I only need to > >> tilt the platform 15 degrees in an hour > >> > >> which should be doable. I would only need 14-15 arc second precision > >> really, per second. > >> > >> > >>> How fast do you need to step? Assume the Earth turns once per day ;-) > >>> That is 1,300,000 arc seconds per 86,000 seconds. Or about 15 > >> arcseconds > >>> per second. So the motor in case number two steps only about 7 or 8 > >> times > >>> per second. So it looks like you could do 1/16th step or even > more. > >> > >> I need to tilt the platform 15 degrees per hour, earth rotates 360 > >> degrees in 24 hours, that is 15 degrees per hour, or 15 arc mins per > >> minute which is 15 arc secs per second. .. which is pretty slow, but > >> the need it to do it smoothly. > >> > >> > >>> But you trade off slewing speed if the microsteps are too small. So > you > >>> want them to be invisible at your optical resolution but no smaller. > >> This > >>> depends on the aperture of the scope and the camera's angular pixel > size > >> right, like that and yes, taking lot's of pics, so vibration is a no > >> no (although that can be fixed afterwards) but ideally, smooth moving > >> and accurate, for compensation, would be best. > >> > >>> But is this az, el or equatorial? And what is the gearing? I just > made > >>> up those examples from thin air. > >> equatorial, the equatorial platform is most important. > >> > >> > >> The idea is. set the platform ready (at 15 degrees "towards" rotation. > >> then move the scope to the object and keep it there. so AZ and Alt are > >> holding. the EQ starts moving, in order to track. > >> > >>> One thing you really want is FEEDBACK from a guide star or even from > the > >>> main camera. A guid camera can detect feild drife and change the speed > >> of > >> > >> sure, maybe some day.. for now I am using rotary encoder .. I have a > >> few 400ppr quadrature encoders lying around, they are very small.) > >> > >> > >>> the motor compensate. Drift is caused by (1) changes in > >>> atmospheric refraction as the target moves and (2) the telescope mount > >>> flexing as the scope moves. Some sophisticated software tries to > model > >>> this and calculate the effect but a close loop is best and now days > cheap > >>> to do. > >>> > >>> Last time I did this we used NTP to keep the controller's clock > >>> synchronized to actual time. We used a local GPS receiver to create a > >>> local NTP server > >>> > >>> Yes, one could use LinuxCNC to drive the motors it might be easier to > >> just > >>> use a microcontroller. > >> > >> That is what I thouht of when I saw an older post about using CNC for > >> an rc model (a plane or so?) > >> > >> > >> > >> > >> > >> So I have the mechanical parts figured out, and how to do some > >> reasonable tracking. What I am after is how to best make the stepper > >> drivers work. > >> > >> > >> With PWM signals I can 'drive' the stepperdrivers and I can move the > >> stepper motors, I am just trying to figure out what the best method9s) > >> are. for example what the connection is between pulses that are > >> longer.. or shorter pulses with larger gaps between them. > >> > >> > >> Ron > >> > >>> On Thu, Jul 9, 2020 at 11:26 AM R C <cjv...@gmail.com> wrote: > >>> > >>>> Hello, > >>>> > >>>> this is (probably) off topic, been seen that happen. If it is please > >>>> ignore it. > >>>> > >>>> > >>>> I am building a "motorized" telescope mount (dobsonian) with what is > >>>> called an equatorial platform, it has 3 axis which I am going to drive > >>>> with stepper motors. > >>>> > >>>> > >>>> The stepper motors I use with a stepper driver, those common DM542 > ones, > >>>> the stepper motors themselves are 2A and 1.8 degrees per step. > >>>> > >>>> > >>>> What I want to accomplish with the equatorial platform) (it > compensates > >>>> for the rotation of the earth) is that, the start and end position > >>>> accuracy is not that important, smooth and constant/consistent > movement > >>>> is. for the azimuth/altitude precision is not a really big deal, but > >>>> you'd want to move these 2 axis somewhat swift. > >>>> > >>>> > >>>> So there are a few factors to decide. > >>>> > >>>> > >>>> I probably want micro stepping, what settings on the driver for > pulses > >>>> per rev, is best to use (or is that just trial and error?) > >>>> > >>>> > >>>> As with PWM itself, I am probably just not too familiar with it. From > >>>> what I understand, the voltage I use for the motors determines how > fast > >>>> I can go (I am going to use a 48V switching power supply). > >>>> > >>>> > >>>> as for PWM, I can of course change the length of the pulse itself > >>>> and, independently, change the time between two pulses. What is the > >>>> relation ship there? WHat does a longer width of the pulse itself > do? > >>>> and what exactly does a longer gap between the pulses do (of course > the > >>>> wider the gap between two pulses the slower the motor turns). > >>>> > >>>> > >>>> for, especially, the equatorial platform, I want to avoid "jerking" > it, > >>>> meaning starting and stopping the stepper motor as little as possible > >>>> and just go at a 'slow' constant speed. > >>>> > >>>> > >>>> > >>>> sorry if totally of topic.... > >>>> > >>>> > >>>> thanks, > >>>> > >>>> > >>>> Ron > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Emc-users mailing list > >>>> Emc-users@lists.sourceforge.net > >>>> https://lists.sourceforge.net/lists/listinfo/emc-users > >>>> > >> > >> _______________________________________________ > >> Emc-users mailing list > >> Emc-users@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/emc-users > >> > > > > > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- Chris Albertson Redondo Beach, California _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
