|
|
|
(you are viewing a thread; or go back to
list of threads)
Possible limitation, bug (by PCauto)
Hello!
I was testing this program thats basically a pulse train output for driving stepper motor.
I has a setpoint for speed, pulses and cycles (in case pulses arent enough for the desired travel of the motor).
And also it sends the setpoints data to a HMI that is a serial LCD (20 x 4, ttl, 9600baud).
While simulating, everything runs right, it counts the steps, read the buttons, etc... BUT, when download to pic (16f887 @16mHz), the program goes crazy... leds blink in a nonsense way, the lcd shows alleatory characters, the buttos sometimes read, sometimes not.
SOMETIMES it seem to stabilize, shows charactes right but then it fails again... tryied with cycles time betwen 1ms and 50ms..Tested with 16 and 20 mHz. none worked stable.
Went to LDmicro, simulated again, everything was fine... but when downloaded again.. same problem..
The hardware was OK.. everything connected in the right place, no mistakes in hardware.
Does the program was too heavy for the pic, or did i do something wrong?? Any LDmicro master out there to look at it or even test?
The program is attached.
Thanks!
(no subject) (by MGP)
You can not transmit all the Characters of row43 at once, use a circulair counter and divide the characters to be transmitted.
(no subject) (by PCauto)
But if i do this, the LDC will not show data in real time, right?? because it'll wait for the counter to send 1 by 1, is that it? wll be a delay when editing before showing the input data on screen?
Could you please change it for me, i didnt get the counter thing. If you have the time. Or if someone else could do it, i apreciate.
Thanks!
(no subject) (by MGP)
You can try this, I have changed row43 and added row44.
I hope it works.
(no subject) (by MGP)
Sorry, I have posted the wrong version.
The diffenrence is the first contact in row 44, the display refresh is not depending of this contact.
(no subject) (by PCauto)
Seems very complex, i would never realize it, really!
Im gonna test it tommorow, ill post the result here.
Thanks!
(no subject) (by MGP)
It's not complex, LCDOSC sets the variable to zero with a OSR.
After each uart instruction you see an OSF meaning the next uart instruction must wait until the previous one is completed.
"
When the row is sent, the variable "display" is incremented by 1, so the next row is transmitted.
When the variable "display" is 4 then the LCD refresh restart with the OSR of LCDOSC
5 rows x 10ms cycle time = 50 ms minimum.
If a row is not sent within 10ms then it will cost you an extra 10ms
Conversely, it is also true, if the row only needs 5ms then you have 5ms time wasted.
You can reduce the cycle time at 5ms when it's too slow.
(no subject) (by PCauto)
Hello MGP!
I'm testing it just now.
Now i get it, it's not complex anymore since you showed me this method that send 1 by 1. I thought that LDmicro itself had the ability to send the data at the right time, thats why i did not have an idea what to do when it went crazy, i thought the code was OK, that was some king of limitation haha.
But, for the results... its working perfectly now! i did some modifications to your code, at row 44, in your code sometimes it showed the "DIR" data wrong since it was sending it before sending the command to put the cursor on the right spot, it was sending the first three lines simultaneously.. i fixed by adding the same variable "display" on each "DIR" line with a comparator.
I reduced the LCD oscillator time, it now sends the data smoothly, not even flicker the display light like before.
I'll let the program here, maybe it'll be usefull to someone else to play with stepper motor drivers haha.
By the way, sorry about my english if typed anything wrong, it's not my first language.
Thanks for the help!!!
(no subject) (by MGP)
I think you have forgotten to change the last instruction in MOV display 5 , it stops sending more data to the LCD.
(no subject) (by PCauto)
True, it works great now. thanks again!!
the correct version is attached.
(no subject) (by MGP)
Maybe you can also try to remove some OSR's especially those between the cursor movements.
These are brief two-byte instructions and can save time.
But I can't test it.
(no subject) (by PCauto)
you mean the OSF's in row 43? i removed them. now each line sends the cursor position and right after, it sends the value ( setspeed, setpulse and setcycle), does this send formatted string instruction waits for itself to complete sending the data before continuing to next instruction in the same line/row?? if so, maybe i could remove all of OSF, and let the cycle run only the comparators and MOV instructions?? Will look like this(program attached).
(no subject) (by MGP)
Like this, I think that formatting the value of the variable takes some time.
Post a reply to this comment:
|