Parallel Port, XP and suspicious activities?

Hi All,

I am trying to connect my Three-StepperMotor Controller to my PC via Parallel port. But whenever I connect it, it heats up and two of those stepper motors jam (I can't move them by hand).

I found out that if I go to my PC's BIOS and change the LPT1 mode from EPP to something else, only one stepper will be jammed (if I change it to Bi-Di system doesn't boot!!:Asus A8N-VM CSM/NBP)

Windows version I am using is XP and no printer is installed.

I have another PC with Win98 installed on it. If I connect my controller to that PC, everything works fine with no problem.

Anybody has any idea?

Reply to
Homer
Loading thread data ...

Microsoft are idiots. It'll work fine inder DOS too !

Graham

Reply to
Eeyore

If it works fine in Win98, you probably need parallel port printer drivers for Windows XP.

icprog.sys *might* work (I haven't tried it yet):

formatting link

Reply to
mrdarrett

Whoops, meant to say "parallel port drivers", not "parallel port printer drivers".

Also, what microcontroller are you using? The above might not work for a PIC, since it's meant for an AVR... any parallel port drivers available from your microcontroller manufacturer's website?

Michael

Reply to
mrdarrett

I stopped updating at Win98SE for just that reason. I can drop down to DOS and just about everything works (I have written about 100 DOS programs).

Even at this level, I have abandon use of parallel ports. I use only the COM ports and communicate in high speed serial to a PIC and take it from there. I also do not even use the (com) handshake likes, just Send, Receive, and Ground. Any protocol is entirely in software. My PIC programmer works this way doing 115,200 Baud bit-banging to send and receive data.

Luhan

Reply to
Luhan

Good idea. I put together a 300Mhz AMD system from spare parts just to read data on my 5-1/4 and 3.5" floppies. In my teenage years I formatted a whole bunch of floppies to non-standard sizes (1.4 MB

5-1/4", 1.75MB 3.5") using the DOS tool FDFormat. Needed the fdread.exe device driver to read the floppies afterwards. Won't work in Windows 2k, but works just fine in '98.

Michael

Reply to
mrdarrett

Homer schrieb:

XP is looking for a connected printer. There is a trick within the registry to stop that, but i don't have it at hand.

cheers Gunther

Reply to
Gunther Mannigel

You need a port driver that will work under Windows XP. Download Inpout32.dll from

formatting link
Copy it into your Windows/System32 folder and write your software using the functions exposed by that driver. It can be used by many flavors of C++ and Basic.

--
Dave M
MasonDG44 at comcast dot net  (Just substitute the appropriate characters in the 
address)

Some days you\'re the dog, some days the hydrant.
Reply to
DaveM

the

Is there a similar driver required for working with the serial port on Win2k?

Thanks,

Michael

Reply to
mrdarrett

Since you're doing Windows development, you should check out the MSCOMM32.DLL library. It's supplied with M$ Visual Basic, Visual C++, etc., for development projects. I've never programmed anything using the MSCOMM control, but just browsing through the documentation on it, looks like you can control the serial port easily, including direct control of the DTR and RTS lines.

--
Dave M
MasonDG44 at comcast dot net  (Just substitute the appropriate characters in the 
address)

Make it idiot-proof and someone will make a better idiot.
Reply to
DaveM

With XP you probably need a driver to allow user level access to the parallel port hardware. I use an application called userport (google for userport.zip) to be able to control the parallel port data and control pins. My page below has some info and simple parallel port control setups.

formatting link

Reply to
Si Ballenger

I'm not sure if this is the problem you are having but XP does something strange with the ports. I'm not sure if its port mapping because of protected mode or what but from what I have read one needs to use a special driver to get at them. One has been mentioned here but there are several. They allow you direct access to the parallel ports(and I suppose serial if you want) and then its like one is running in dos except for the timming issues due to multitasking(and by having an optimally configured system you can get close to the performance of dos(if not better in some respects)).

One thing I have read is that one shouldn't used the ECC mode for parallel ports. It does something funky in XP or causes some problems with simple communication.

Also, if you plan on driving large loads you have to use a seperate power source and driver. The ports cannot source much current and will lock up if they try, atleast I think ;/ I believe the max current they can source is about 25mA's or so. I'm not sure if this jives with it working in 98 but not in XP but it could(as XP might do something else).

Why not try to drive LED's or osmething instead and see if that works? If its the same problem then maybe its the code? If not then its the hardware.

Oops, you are trying to interface a controller with the parallel port. If this controller doesn't draw much current then there should be no reason why it would heat up(hopefully you are not trying to pull the current from the pp to drive the motors). Maybe a stupid remark but make sure your connections are correct. Its kinda hard to say what could be wrong without know exactly what you are doing. It sounds like if it getting hot then its probably a problem with the hardware because even using the ports wrong shouldn't cause it to heat up. The only way it can heat up is if its pulling to much current... but surely the controller doesn't use that much current? (which means you got something wrong) If you can't figure it out then you might want to post a schematic or even a photo of what you are doing(as you might have hooked up something wrong).

Reply to
Abstract Dissonance

the

You don't need a driver to be able to control the serial port. The standard Win32 API has functions for controlling the handshake lines as well as for sending and receiving serial data.

There are vast numbers of libraries available that wrap this API if you don't want to use the low-level interface (although that works perfectly well).

Reply to
David Brown

By far the most common parallel port access driver for NT, W2K and XP is "giveio". A substantial proportion of the other drivers are simply renamed versions of giveio (it's source is freely available).

To use it, a program simply opens a handle to the driver, and then can access the parallel port (and other hardware) directly, just like in DOS or toy windows.

If you have an old DOS / Win9x program that you must use under NT, etc, but can't change the source code, then there is a driver called "totalio". When started, *all* programs get direct access to *all* hardware, just like with Win9x.

Reply to
David Brown

A lot of 3rd party printer drivers will hog your parallel port, and dont forget that most of the drivers shipped with XP are not written by MS and will do the same thing. What you need to do is disable any installed printer drivers, printer or no printer.

How are you talking to the port? What language?

There is a few windows api functions that will happily write to the port, without the need for a driver. If you do some research on kernal32.dll and its CreateFile and WriteFile methods you can easily write to the printer port. Most decent programming languages will let you call into the win api these days.

Reply to
The Real Andy

Sorry guys but it seems I didn't explain my problem well enough.

I don't have problem talking to the port (this is next step). I have UserPort.zip (or something like that) to remove WinXP's protection when I get to that point.

The problem is before that. My question is Why do I have mixed High and Low on my DataPins of my WinXP machine.

Here is the example: I connected 8 LEDs to my Win98 machine's parallel port. And I see them all OFF (or ON depends on how I put them). And when I send something to them they change (Using Debug/Basic/C,...)

I do the same thing with my WinXP machine (that has a newer motherboard too). And I see some of those LEDs are ON and some OFF (4 ON and 4 OFF on EPP in BIOS and 3 ON and 5 OFF in ECP mode). Something is putting Data on that port and my question is What is that thing and how can I kill it.

Thanks,

Homer

The Real Andy wrote:

Reply to
Homer

Well, WinXP will initalize the (printer)port at boot time and you see the last data written do the (data)register. It will stay there until it's changed by a printer related command or by yourself using giveio or similar driver. A lot of info regarding ports can be found on:

formatting link

petrus bitbyter

Reply to
petrus bitbyter

I suggest you use a meter to test the state of the data pins instead of trying to use LEDs. The LEDs I tinker with draw ~30ma which may be beyond the capability of some of the data pins on your MB. Does the reported state of the data pins match what you see with the LEDs?

Reply to
Si Ballenger

Because some ports are inverted. You need to check out the internet to get the full spec of how the printer port works instead of guessing. you have pins like the strobe, error, data, and ground. (make sure you are grounding properly too).

Some pins are inverted and some pins are on by default. This might also change with the different modes of the parallel port. You really should look more into how the parallel port works before assuming that simple.

Reply to
Abstract Dissonance

I am not sure why you got to the point that I am guessing something.

I know about the pins and parallel port (electronic part) pretty good. And the LED circute I made works prefectly with my other machine with Win98 (or my laptop with Linux). My Only question is what WinXP is doing to this port while no driver is using it and how to disable it. One answer was XP is looking for Printer on Parallel port and that's why I am getting signals. and it was a talk of a way to disable it. But I don't know how to do it.

Abstract Diss> > Sorry guys but it seems I didn't explain my problem well enough.

Reply to
Homer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.