New song - Hungarian Rhapsody No. 2 - on step motor

We proud presents to you... Hungarian Rhapsody No. 2 played by stepper motor

Details:
48 steps - 4 microsteps
song played 2 octave high
single tempo for all track - the tempo has not been found inside MIDI.
However the players get right?!
7Khz Max frequency.. but stepper dont work direcly on this speed
- need sinuodal rise of speed. need work on this yet.

The hardware to generate sound.

Here the pic of hardware to suport sound generation.

 Too a screenshort of progream that control all.

 And here other song played by steppers' motors!

Pachelbel's Canon
The motors are running in 4 microsteps. But the right one are with bad noise.
Aslso the song are being played 3 octaves high, for better sound.

See too Hungarian Rapsody nr2 

First Test in speed control for stepper

I end the PIC program to control speed and a Windows interface to control and test the PIC program.
Soon as possible i will post the block diagram of PIC software.
Bellow a video of singer steppers made by my.
It are playing BigCity.mid song in 2 voices!
The bushless are better to make noise.
Using 2 motors for old Epson printers.
Using the driver from board of one old Epson to control both motors. Too using the power supply, to supply 5V and 42V.
But PIC are controlling the motors.
The pic receive the commands over serial, from windows, in XYZ and LENGHT over time numbers.
So PIC control the step generation.
It's like the "Dueling Steppers", found on Youtube.
Enjoy!

CNC SPEED Control

Since then we talk about accurate control multiple axis, we should remember that all axis speed get together based in pitagoras equation in simple orthogonal system (XYZ system). Based in simple 3 axis in orthogonal system (90°), each one running at 30mm/sec, the final speed can be calculed as SRQT(X^2+Y^2+Z^2) and must be aprox. 51,96 mm/s. That is just a exemple... but show that the final speed must be corrected in all axis in a sincronized way.
So if you control just indidually each axis, you dont get the right speed.

Based in this "problem" I made a "algoritm" to control the final speed for use with simple microcontroller.
I think that was solved by many commercial and free softwares already, but for my CNC, i appreciate implement it.
It generate 4 simple data that can be user by any microcontroller easyly with fixed math to controll accurately the speed of all axis for each line it process, getting always the right speed for final movement as desired, and based in clock that microcontroller will drive the motors (INT clock!). I implement the initial idea using excel; so as I align and clean everything in the file, I will put the excel file here with formulas.
By the moment I just show to you the most precisous part of project.
The schematic of all thing! Its a huge image(3000 x 1500 px), so be patient!

I blend portuguese and english, but all we are smart enough to get the right understanding.
Basically, I get all the XYZ real data, and process it to get the the accurate speed and shift values. Green boxes represent the input data, by user or by stream of line to be processed. Blue boxes represents the simple data to be send to microcontroller. As inexpensive microncontroller work nice with fixed math, and there are lots of code for fixed math, its much more easy to use it, I make everithing thinking in that way. The output of algoritm use a fixed floating point for control each axis, based in microcontroller interrupt CLOCK, and with a Npassos amount of steps to be run by clock. I make the reverse calculus in Excel, based in rounds that pic will execute, to see if everything runs nice. The final data show great, with little error. Since we use more that 4 decimal places behind the dot. (0.xxxx)
The system to admits that we can use variable size step motors and variable speed reduction for each axis (like the screews of diferrent kinds). The final speed, given right values, will be garanted.
I dont make a analisys to get the MAX final speed supported by the system.
BUT have in mind, the X || Y || Z OUTPUT DATA must never be great that ONE; if this happen, some are wrong...
the desired speed are to HIGH for the choice CLOCK; you must put higher CLOCK (but you can get problems with frequency suported by your steep motors, it can hung); or you have to use a more fast XYZ transfer axis(screew); or fast step motor with little steps per revolution. It's your choice.
By now are too hot here, and I have to lunch. Soon as possible I will post the remaind of project.

One more home made MDF CNC

Now I will start to present my ideas and project about build a home CNC (or engraver?)
I define it bringing the reality of parts more easyly avaliable here, in my city and country; I live in  inner city in southen Brasil; a little different from USA and Europe, where is easy to find allthings; here is hard to find some kinds of parts; so I am adapting as possible the parts, as all others, to build my CNC; also I have tiny space to build everything.
I have in mind build all the electronic hardware.
Also I want to use other aproach for the software e and IOlines to control the motors; want to use bipolar motors; homopolar are too noise. Yet, the use of parallel port are to much exausted by all others CNC builings; I want to bring some new. Soon as possible I will post all the specs. I just like to note I preetend make a nice speed control to CNC.
I define all the project and now starting to cut the parts in 1.5 cm MDF;
Also should mention I will use IGUS parts, due to easy that its offer to build this kind of project; We have a good regional reseller for this parts. I already buy its and soon will post the IGUS's photos; I have its since a year ago, but dont have spare time to build the entire system. until now.
Bellow the image of I hope to become the CNC.
The 2 axis XZ are fixed and Y work above X (or Z).
Soon a post more about the project.
Sorry my poor english, but I not a good english writer.
I want to put all the software here too.
If you have some suggestio, please, dont think twice.
tell me! ;) I will appreciate!

The Fix of Manchester decoding routine code from Michochip (keeloq) - Tb 045

Manchester decoding receive routines from michochip datasheet (presented for keeloq system) is a great and easy way to start work with remote control systems. The first part of this fix are in here.

The document TB045 of microchip offer code for everyone that own microchip controllers to use, and guide to the basics to Manchester decoding , through the implementation of a state machine.

I implement and test a system, based in code of TB045.
Also, implement the Manchester transmitter code, and it is enough simple.

Beyond basic systems to transceiver serial data, believe that Manchester encoding allow robust data reception, and is very stable.

However, after implement the system, the transmitter and receive, I discover that not work at all so well. Let me explain what I do..

I build the transmitter code, that is very stable and precise (interrupt based).
Also, use 2 segment display to show data being received on receiver side, with pic.

I know what data was being transmitted (by transmiter ). I check with my "ociloscope audiocard" and, all times the data are transmitted nicely (the waveform are just perfect).

So I use a typical transmitter/receiver 'made in china' to transmit and receiver the data over the air.

However, the problems begin.

Each ~10 transmitted burst of data, the receiver don’t understand one sequence of transmited data. Upon 5%. (I am talking about a complete burst of data, with many bytes). Also other times it get the data, but very wrong.

I will show to you the pictures bellow that show the transmitted code and received one.
You can implement the native code over PIC (not over arduino, microchip not allow this by this terms) too and detect this.
The problem is that anyone that try use this code, due the small percentages of problems, never will take real care about; but the problem still is there.

Maybe commercial products has been release with this bug… that disallow the perfect opration of entire system….

So let’s start!

The first problem detected was the error in receiving nice code.
I look with oscilloscope (audiocard) the received code at pin of receiver, and everything seen correct. Even when receiver PIC decode the wrong data.
And also stay tune in what the PIC-receiver are saying about the received code.
But some times the PICs lost it self, and detect wrong data.
So I start investigate the keeloq receiver routine.

Since the sender routine is nice, and my code inserted into the receive routine really not interfere in the manchester decoding, I look in the interrupt driven routine of manchester decoding routine.

But before, let me explain how I debug!
The manchester decoding routine use four (4) main state machine. State 0 to 3. Look to TB045 to learn more.
So I just insert inside each one of these states BCF and BSF instruction, to set and reset unused PIC pin.
Now I know exactly where the “pic” is running during the tests and more important, during the errors.

Using the two channel audio card I get the data and the behavior of state machine.
Bellow you see the CODE of debugged version.
After analyze code and states througt the pin that say for me the actual state, when the error occurred, I found the flow problems.

The system detects the preamble as valid signal and start to sampling data. Preamble is a sequence of 0 and 1 send by transmitter used to stabilize the receiver before start to synchronize and send the data.

Almost always 0xFF 0xFx etc and some other wrong data are received in this cases, then the data are get wrong.

But why this thing happen?
The system would be nice, and the preamble would guarantee that everything is working fine.

It was possible to detect through debug data lines that the state 2 are starting just right in preamble start. Much stranger!

But this happen sporadic.
So I go to the code try find what are happening.
I look just before the execution of state 2, in state 1, who start state 2.  Bellow the code.

See the original code: (page 6 / 7)
;----------------------------------------------------------------------
; State 1
; Waiting and measuring a Synch Header
TRFSync
btfsc RFIN ; wait for a rising edge
goto TRFRise
incf RFsamp,F ; while input low count the samples
movf RFsamp,W
btfsc STATUS,Z
goto TRFReset ; check overflows (this should not happen)
incf RFSkip,F ; skip = 1
goto AsyncRFE ; remain in state 0

When the TRFReset happen, because of RFsmaple overflow, the RFsamlpe are reset to 0.
Whoever, it should not be reseted. It should stay in a high value. Think with me: during no transmission, the signal is always 0. So RFsample stay running and counting higher and higher. But if an overflow happens, (256), the RFsample is reset to 0, and start count again. If it count until 4 te, (sync), and the preamble comes soon, the machine detect as a valid sync signal, and start to sample! As the RFsamble is reseted every 255 cycles, is likely to this happen. So to fix this problem, we just maintain the counter of RFsample higher if it passes the maximum size of allowed counts. Prefer higher than constant LONG_HEAD; but bellow 255, so if not happen any preamble to force a reset, the system never get out this state, and no cause lost in data in! Ta ta! Bellow the fixed version.


. . .
;----------------------------------------------------------------------
; State 1
; Waiting and measuring a Synch Header
;
TRFSync
       ;bsf LED_STATUS0
       ;movlw 0x1
       ;movwf display
       btfsc RFIN ; wait for a rising edge
       goto TRFRise
       incf RFsamp,F ; while input low count the samples
       movf RFsamp,W
       btfsc STATUS,Z
       goto TRFCorrige ; we create a new way to code follow; If it go here, mean that a long time pass and no more valid sync will happen
       ;goto TRFReset ; check overflows (we eliminate this)
       incf RFSkip,F ; skip = 1
       goto AsyncRFE ; remain in state 0
TRFCorrige
       movlw 0xf0   ; we set the “border” almost in the limit, just to make sure that never will accept any code before the first bit of preamble
       movwf RFsamp ; and move to RFsample
       incf RFSkip,F ; skip = 1
       goto AsyncRFE ; remain in state 0
TRFRise
. . .

This force the code to stay waiting for preamble, and first bit in preamble reset the counter throught TRFRise, where is the right place for TFRReset to be called.
After this change, the receiver routine no more shows the wrong behavior.

Looking deeply I found that the routine in state 3, TRFFull have a error too: see bellow:

TRFFull ; received them all
movlw TRFReset ; next state will be Reset
movwf RFState
bsf RF_Full ; set the buffer full flag
goto AsyncRFE ; done

I smart look can reveal the problem. The variable RFState must contain just a value between 0 and 3; but here, we are assigning a pointer to memory position of TRFReset to it. And this is always a enigma data; that might be 0, may be 1, ou 10 or 60 or any pointer.

Fixed version is:

TRFFull ; received them all
movlw 0x0    ; the state, not he memory position
; movlw TRFReset ; next state will be Reset (wrong)
movwf RFState
bsf RF_Full ; set the buffer full flag
goto AsyncRFE ; done

I think that is a simple but nice help for anyone that think in use this code.
I have the fixed version of this code; but above you can copy and paste and use the code without fear.
However I don’t responsabilyze about any problem that this fix can cause!
By now, just rest to say that I appreciate you opinion about the article.

Argumentação através da Intimidação

Isso está sendo muito utilizado nas empresas na atualidade.
Vale a pena ler.
Lembra-me aquele ditado.

Manda quem pode, obedece quem tem "juizo" (medo).

http://akitaonrails.com/2009/09/12/off-topic-a-argumenta--o-atrav-s-da-intimida--o