Visual Basic Controller - pulse width?

[dwwright]

Hi all,

I've been playing around with creating controller software in Visual Basic. I've had good luck in creating a Jog controller that works. I can get all the motors to spin in the correct direction, however not very fast. I've played around with several different timers from milliseconds to microseconds, to nanoseconds, but I can't seem to get the same speed that other controller softwares are getting. The dll I'm using is the same one that KCam is using for interfacing the parallel port. Does anyone have a good idea what the pulse width should be between steps? I'm betting that it has something to do with this, but haven't had much luck.

Thanks,

Darren

[RotarySMP]

KellyCAM is the worst pulse train generator I have tried, so using their DLL is probably not a great place to start. There is a reason many G code interpretors are still running on DOS, and that Art went great length to get control of XP for his Mach2.

Sorry.

[dwwright]

Originally Posted by RotarySMP KellyCAM is the worst pulse train generator I have tried, so using their DLL is probably not a great place to start. There is a reason many G code interpretors are still running on DOS, and that Art went great length to get control of XP for his Mach2. Sorry.

I realize that it is not the best option, but I'm using this as a learning experience to "enhance" upon. I'd still like to find out what I'm doing wrong. KCam can move the motors about 5 ipm, where I can only get a 1/10th of an inch if that.

Thanks for the feedback anyway.

Darren

[Rekd]

If you need accuracy, try using GetTickCount instead of a timer control.

[Swede]

If you're using a DLL, then you know what you are doing with VB. There are several freeware DLL's that hardware-write to the parallel port. I used one for a CNC coil-winding machine with VB. The DLL I used is inpout.dll. Here are the declarations:

'Inp and Out declarations for direct port I/O in 32-bit Visual Basic programs.
Public Declare Function Inp Lib "inpout32.dll" Alias "Inp32" (ByVal PortAddress As Integer) As Integer
Public Declare Sub Out Lib "inpout32.dll" Alias "Out32" (ByVal PortAddress As Integer, ByVal Value As Integer)

This DLL is well-behaved and used quite a bit by VB guys.

Swede

[dwwright]

Originally Posted by Swede If you're using a DLL, then you know what you are doing with VB. There are several freeware DLL's that hardware-write to the parallel port. I used one for a CNC coil-winding machine with VB. The DLL I used is inpout.dll. Here are the declarations: 'Inp and Out declarations for direct port I/O in 32-bit Visual Basic programs. Public Declare Function Inp Lib "inpout32.dll" Alias "Inp32" (ByVal PortAddress As Integer) As Integer Public Declare Sub Out Lib "inpout32.dll" Alias "Out32" (ByVal PortAddress As Integer, ByVal Value As Integer) This DLL is well-behaved and used quite a bit by VB guys. Swede

This is actually the one that I'm using. Perhaps I'm doing it wrong? I'm using a time delay (about 6 microseconds using CreateWaitableTimer) between Out commands as a slight pause. when the commands were sent on after another without the pause I wasn't getting movement.

Thank you for your input...

Darren

[Swede]

Hi Darren, it's been a long time since I worked on the code for my Coil Winding machine. So if I ask stupid questions, it's definitely me!

Are you actually getting 6 microseconds, or did you mean milliseconds? 6 uS is very quick, 6mS is more typical of a VB timer control.

I remember distinctly attempting to use the timer control, which for me was a total bust. Ultimately, to control speed, I went with iterative loops which did nothing except burn CPU time between output writes to the port. The BIG problem with that is there is no simple way, when moved to another PC, to obtain exactly the same speeds, it was a matter of trial and error. Further, the operating system would hang when in the loops. My program was never designed for advanced motion control, so I did not need to interpret G-code or do anything beyond electronic gearing, which it did very nicely, thus I did not have to really push the envelope in the code development phase.

I remember one of the hardest parts of my code was in creating a smooth and gentle ramping, as the ultra-fine copper wire would break if I simply turned the motors on with a sudden pulse stream.

I'm using Flashcut as a CNC control, and while Window's-based, they use a chip in what they call a signal generator, and feed the signal generator a serial stream of data. This avoids all of the horrible timing issues inherent in Window's software.

I would recomend that you have distinct functions which can be called, with each call producing one step of the motor. Thus you can insert that call into a loop, with whatever needed delay as a part of the loop.

Sorry I couldn't be more helpful; I don't think there is any kind of magic wand one can use to avoid Windows timing problems.

[dwwright]

Originally Posted by Swede Are you actually getting 6 microseconds, or did you mean milliseconds? 6 uS is very quick, 6mS is more typical of a VB timer control.

Swede,

I actually am not using the timer control but the CreateWaitableTimer of the kernal32.dll. You can code to microseconds using it.

I appreciate your advice and sharing your experience....Thank You.

Darren

[Swede]

Hi again Darren,

I never had any problem with the motors going too slow! There may be hardware differences between our setups. The little CNC machine I made used two 200 step 5.25" floppy drive motors in an electronic gearing configuration. Each motor used a "Ramsey" hobby-kit stepper motor board, capable of 500mA. I don't remember the chip, but to get the motor to move required two things - first, the chip's ENABLE line was taken high and left there. The chip then had more logic options - one line was half/full step; another was CW/CCW. Finally, to actually make the motor take a step, I took a CLOCK line high, then low. The act of toggling the clock line actuated the chip and thus the stepper.

It seemed that the chip was quite fast... I did not have to "hold" the CLOCK high for any length of time, simply cycling the clock high/low did the trick.

'Where bit 4 is the clock
'Take CLOCK high:
Result = Out (Addr, 1111 0000)

'Take CLOCK Low:
Result = Out (Addr, 1110 0000)

These two lines back to back would step the motor. I was using VB6, compiled, not interpreted. The speed of the motor was regulated then by whatever software delays I created between CLOCK pulses. I found to my irritation that a standard timer control was too slow, and without using the Win32 API, just wanting to get the project done, I executed a nested FOR:NEXT loop, varying the duration of the loop. This worked great on an old Pentium 2 computer. Of course, when I moved the software to a 2.6 gig P4, the motors screamed and lost steps!

I rewrote the code, using handy CONSTs to better time the system. It ultimately worked out OK.

You sound like a fairly advanced VB guy... if you haven't done so already, I would recommend creating a TYPE variable, something like so:

Type MotorVar

Name As String * 32 'User Definable name
PosAbsolute As Long 'Absolute Motor Position
PosRelative As Long 'Relative Motor Position
Target As Long 'Target Position
StepType As Long 'Half or full step
Direction As Long 'FORWARD or REVERSE
Delay As Long 'Looping Delay for motor
Slope As Long 'Ramp, higher = slower
SlopeReg As Long 'Temp math register
BitPattern(0 To 1) As Integer 'Value written to PortAddr

End Type

It makes dealing with the motors MUCH easier overall.

This has been a lengthy post... I don't know if I've been much help. If you'd like, PM me and I will send you the whole project, saved for VB6. The code is well commented and decently structured. There may be some tidbits that might be of use, especially the ramping aspects which were pretty tough.

Again, Good luck!

Swede

[dwwright]

Swede,
Thank you for the feedback and info. I did code using variables as well as an INI file. I found I had an optimization issue in my code and with the CreateWaitableTimer am now getting about 4.5 ipm. I did recode again using a for/next loop and was able to get about 26 ipm, but it did skip a few steps. My table is using all-thread with delrin nuts so I have a hard time getting over 10 ipm with the 80 oz/in. motors, so it is plenty fast for my needs. I have moved on to coding a g-code interpreter. I'm using some dxf source code that I found at http://home.datacomm.ch/reto.knaak/dxf.html, which was a big break. I'll post the source code once I get a little further along. Attached is a screen shot.

Thanks again,

Darren

[dwwright]

I added code tonight to jog using a joystick. I'm currently using a joystick to keyboard mapping utility for KCam. I thought it would be nice to incorporate one in to my program. Also programming a couple of buttons to set the zero axis so I can set the machine without walking back to the computer to click the buttons. I also started coding the gcode interpreter.

Darren

[Swede]

Very nice Darren. I've been tempted to explore the use of VB to make some custom apps for my Logosol system, which uses serial commands. Logosol kindly provides VB source code and some examples as well. A full-blown g-code interpreter is quite a project.

Have you considered a PIC or similar chip? One could program the PIC to act as an offboard buffer. Feed the PIC commands from your VB interpreter via RS232. The PIC could stack them and process them, and ultimately you'd never have to deal with Windows timing issues again as the PIC would time the commands.