SX-Key v3.10 Crashing and bug...
dkemppai
Posts: 315
Hi guys.
Several times in the last few days, my SX-Key software has crashed on me. It seems to happen during an assemble routine. This is usually after I've assembled code many times before.
Also, every once in a while the debug window pops up with a really big font, enlarges the windows to a massive size,·about 2 times normal size. If I close the debugger, and debug again, the font size stays large. The only way to fix the problem is close the SX-Key V3.10 software, and open it again.
Any ideas?
-Dan
Several times in the last few days, my SX-Key software has crashed on me. It seems to happen during an assemble routine. This is usually after I've assembled code many times before.
Also, every once in a while the debug window pops up with a really big font, enlarges the windows to a massive size,·about 2 times normal size. If I close the debugger, and debug again, the font size stays large. The only way to fix the problem is close the SX-Key V3.10 software, and open it again.
Any ideas?
-Dan
Comments
And a third bug. This time with SX sim (I think)
I installed the SX-Key V3.1 software to my home pc,
and ran it for the first time. This was the error message
I received. (See attached file)
The current version of [url=mailto:comdlg32#@.ocs]comdlg32.ocx[/url] that I have installed is dated
1/16/1997. I'm running WinXP SP1.
Shouldn't SX-Sim install the correct activeX control when installed?
Any insight?
-Dan
Now, the software crashes in the middle of a walk.
I'm starting to get really upset here. Does anyone
have any ideas?
FIFO settings on the com port, anything???
If anyone has Ideas, I can try to help troubleshoot things.
Help, anyone?
-Dan
P.S. Getting Very frustrated. I have 8 years
of windows computer maintenance/repair/administration.
I write windows software that's being used in
fortune 500 companies myself. I design the corresponding
hardware myself! My customers don't have even close
to this much trouble. At this point, I would start to expect
a little more from a software package that I first used
in 1999 (It's almost a freaking decade old!)
It's late, and I've been programming for 18 hours.
Enough ranting, going to bed now.
P.P.S. Why is this web page defaulting to double space again???··
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There are 10 kinds of people in the world.... those that know binary, and those that don't.
for my part, I can only answer the question concerning SXSim in full detail:
Since I have published the first version of SXSim, I only posted the EXE file, no Setup package, in order to keep the size of the download small, and also to avoid that users overwrite their versions of COMDLG32.OCX and possibly other OCXes and DLLs with those versions that are used here in Germany, where I live.
In the past, I think I only got four, or so problem reports that an OCX was missing or incompatible. If you look at my first post in the "sticky" SXSim thread at the beginning of this forum section, you will notice that I have posted a version of COMDLG32.OCX there for download that I'm using here. Please download this version and copy it into the folder where SXSim.exe resides (not into the WINDOWS folder) to avoid that your version is overwritten. SXSim should then work as expected.
Seems to me that your version of COMDLG32.OCX is not the one that usually comes with Win XP as it is dated 1/16/1997 which is way before Win XP was released, and this explains why it is not compatible with SXSim - or should I say SXSim is not compatible with this OCX?
I'm not involved in the development of the SX-Key IDE but I did a lot of beta testing in the past but I never had problems like the ones you describe. There were some nasty incompatibilities with Win XP in former versions, causing stuck dialog boxes, etc. but this has been definitely fixed in the current version.
Over all - the SX-Key software can't be that bad as you believe as there are a great number of users around who use it without trouble. To my believe most of these users have even less experience in computers/software compared to the experience you claim to have.
I'm pretty sure, others will bail in here with more ideas what might be wrong with your installation of the SX-Key software.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
Edit: Actually two different computers. One is WinXP SP1, the other is WinXP SP2...
-Dan
Post Edited (dkemppai) : 7/21/2005 2:46:19 PM GMT
Guenther,
Can you tell me what version of the Comdlg32.ocx you use? I can manually unregister my version, and install the version that you are using. I'm surprised that since SX-Sim is included in the install with the SX-Key software, the correct ActiveX controls are not installed with the SX-Key package. I tried to to delete the SX-Sim program from the SX-Key directory, but the SX-Key installer tried reinstall it, then crashed. I was hoping that I could just delete the sx-sim executable, and be on my merry way. But no luck.
As for the reason that I have the older version of the OCX, it may be that the older version is installed with my copy of Visual Basic 5 (Which tends to install older version of Controls). With the older VB5, I do not have the liscence to use the newer controls.
My biggest issue (Of course, it's not part of your software) is that SX-Key program crashes when running debug/walk. This makes me think that there is a bottleneck somewhere in my PC hardware or the program that cannot keep up with the SX-Key. I'm going to try a different SX-Key (both are Rev. F), and try a USB to RS232 serial port. I may have to try a reinstall of my OS, as a last resort.
Overall, I've been using the Parallax SX-Key periodically since 1999. I really like the software, but on some PC's it just won't run. I use the Parallax stuff, because of the level of support, ICD, and guaranteed supply chips. I own several SX-Keys, and even recommend them to some of my customers. (I have a day job using them, and a contract engineering business using them).
Everything I do is small quantity/high margin. So, parallax is a perfect fit.
I just can't seem to hammer out these software bugs.
-Dan
my version of COMDLG32.OCX is 6.0.84.18 (at least, this is what the Windows file property dialog reports). Instead of unregistering your version, and installing the new one in the Windows\System32 directory, I suggest to copy my version into the folder containing SXSim. To my knowledge, OCXes, and DLLs are first searched in the executable path, and next in the Windows paths. This would keep your oringinal COMDLG32.OCX intact, in case it is needed for some VB5 applications on your machine.
The SX-Key IDE is a bit tricky about add-ons. Whenever it is launched, it checks if the SX/B compiler, the associated help file, SXSim, and its doc file are there. When it finds an older version, or no file at all, it automatically installs the missing/newer files which are appended as ressources to the SXKEY.EXE file. You are right, it would be a good idea to also install the required ActiveX controls, and I'm pretty sure that the next version will do that. For now, the recommended workaround should help.
Nevertheless, while the SX-Key IDE installs add-on components, it should not crash, and it normally does not. I did this on my machine (Win XP, SP II) quite often w/o trouble.
While running debug/walk, the IDE, and the SX-Key hardware communicate via the COM port used to connect the SX-Key. I don't know the exact Baud rate, but to my knowledge, it is relatively slow, so there should be no "bottleneck" effects. Nevertheless, some users reported that changing the FIFO size of the COM port driver, or turning it off completely, did help (but this was with older versions of the IDE) - you might give it a try.
You might also check with Task Manager if there is another process running on your machine "eating up" a remarkable part of the CPU time. Task Manager would also help you to see if there is more than one instance of the SX-Key software or SXSim active. I found this happen sometimes when using Win ME, but never under Win XP. Nevertheless, it's worth a try.
Looks as if we are in a similar business. Currently, I'm making most of my income with SX-related (fortunately, this now means with Parallax-related) projects. My first SK-Key was one of these devices which came with the short serial cable attached to the Key (not that bad - took away mechanical stress from the Key). In the meantime, my business seems to turn from "small quantity/high margin" into "large quantity/(hopefully still) high margin"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
·· Just out of curiosity have you tried a lower value for walking?· Lower than 8.· It is possible at higher speeds you may be having the problem.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
I do have the·6.0.84.18 of the control at work, so I will try that. You may be correct that I can·register the control in a directory other than the Win/Sys directory. In the worst case, I will manually remove all references to the control from the registry (I've done this more times than I care to count) and install only the version SX-Sim wants.
As for the FIFO, I've tried full size all the way to zero and even disabled. None of that helps.
The next thing is to try a USB->RS232 converter (Based on FTDI Chip/Really fast SIPEX TTL<->RS232 converter). I'm a little hesitant to do that, because I use the FTDI parallel version of the IC in my hardware. Since the Parallel and Serial version of the FTDI chip use the same default PID/VID, there may be some Direct Driver vs. VCP compatability issues (I use the direct drivers for my hardware). I'm also going to try a different SX-Key. It is possible that the my·hardware is the problem, but I doubt it.
I think that it's a bottleneck issue, because as I slow the walk speed way down, the the problem virtually disappears. Running full speed, the thing will crash within 5 seconds of starting a "walk".
The SX is a small portion of·my work.·I do mostly harsh environment (+170 degree C ambient)·analog electronics,·SMPS design, and some industrial control applications and all the circuit board design for my apps.·I use the SX in the·less harsh control/datalogging applications.·I was lucky enough to land a job·doing what I like...· ...then ended up with starting a hobby·company doing even more of it!
Also, the CPU time is +95% free. I usually try to keep active processes to a minimum. (Windows stuff, and only the software I really use). The PC is a AMD AthlonXP with a 2Ghz clock on a MSI K7N2D board, Raid drives, 1Gb ram, and fast GeForce video, so it should be plenty fast. (Maybe too fast???)
BTW, Thanks for your encouragement. I was getting really frustrated last night!
-Dan·
Post Edited (dkemppai) : 7/21/2005 5:15:54 PM GMT
-Dan
Post Edited (dkemppai) : 7/21/2005 5:16:13 PM GMT
Do you by any chance have a serial cradle that require syncing. Hot-sync is known for these kind of problems.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - PLJack - - -
Perfection in design is not achieved when there is nothing left to add.
It is achieved when there is nothing left to take away.
The SX-Key software likes the USB-RS232 converter. Very stable, although debug/walk is very very slow compared using the onboard hardware.·I'm sure that the lack of speed·was due to latency delays in the FTDI hardware·and PC overhead.·The default latency for the FTDI chip for data packets under 62bytes is 16mS (unless CTS#, DSR#, DCD#, or RI# are changed in that period). That means, unless all data sent to·the PC is in 62byte blocks, the last bunch of bytes will be delayed by 16mS, and thus the reason the USB-RS232 adaptor is slower.·To speed up transfers, make the bunch the data in packets that are multiples of 62bytes, or toggle one of the above listed signals very often....
Now, My question is, is the software more stable because of the longer latency delays and buffering afforded by the USB/FTDI Chip, or is it the port?
All loopback·tests I've run on that (my only hardware) RS232 port·not had any errors....
Gunther,
·...Anyway, the suggestion didn't work.·
Pathless .DLL components are searched for by .exe path then winsystem path (as you suggested). Com components OCX's, Active X EXE's, ActiveX DLL's on the other hand are located though the registery.·I think the problem comes into play, when the installer doesn't supply it's own version of the Control. WinXP is supposed to utilize a side by side installation, where all versions of a control are stored, and supplied to each program that installed it, as it is required (Yes, very counterintuitive considering the purposes of DLL's in memory and HDD). That is to say, if you install a Control with your program WinXP will supply that very same Control·to your program when your program tries to use it.·The problem is that SX-Sim didn't install the control, so windows defaulted to the one in the Windows/System32 directory...
To continue (breathing again), I've never installed two individual .exe files with the same installer·(Any of the additional .exe's I install are ActiveX EXE's and get registered into the registery). Using one installer for both the SX-Key and SX-Sim may not properly tell windows which files to user for SX-Sim. I just don't know the answer to that one.·I'm guessing that the parallax software didn't install comdlg32, or WinXP didn't know that SX-Sim needed the version installed with SX-Key (if it was installed)·and thus the older version I had was used.
I think that I will have to remove all references to the comdlg32.ocx and install the version that SX-Sim wants in the Win/System32 directory.
The probelm is that I do my development with the older versions of controls to prevent this exact probelm with my software. Any Software·should use·newer versions of the any control because Controls are supposed to be·backwords compatable.·SX-Sim,·for example·was developed with a newer version. Without the proper installer package to upgrade control (Older windows versions) or supply it·to·be cached it (WinXP,Server2003...) the program crashed.
Did this make sense or is my head stuck somwhere in the seat of my pants?·
-Dan
P.S. I've posed similar sized/complex rantings on this·board in the past with absoutly no response...·· ...I hope this thread won't die just yet.
The best way to test that is to connect another high speed serial device to that port.
If it locks up then you have a hardware / Windows OS problem.
If not then you have a software / corrupted common file problem.
You would be better off talking into the mouse and asking the port if it is okay than a loop back test.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - PLJack - - -
Perfection in design is not achieved when there is nothing left to add.
It is achieved when there is nothing left to take away.
I'm thinking it's the software. It's the ONLY software that I've ever had probelms with on this computer.
Is there any way to enable any debug/logging options in the SX-Key software. Like an option that would create an error/progress log file.
-Dan
·
How about the software crashing on my third computer! A stock standard toshiba laptop.
When I first started the program, it asks me to set a few options the first time around. At which point it poped up a message "List out of bounds (-1)" and promptly crashes. After a few minutes, I figured that the default com port was looking at my modem. I would have expected·the·"SX-Key was not found on Com X" message, not a·crash.·
I still can't get it to start without a warning error on my main PC.·SX-Sim keeps crashing.
Gunther,
Might you consider changing your code a bit? It is possible to·use classes which display the Common Dialog Open/Save windows without actually using the control. I'm not sure which language you are using, but here is a VB example. I'm sure there are others for C, etc.
http://www.vbaccelerator.com/codelib/cmdlgd/nodll.htm·(Here's a VB Example)
-Dan
looks as if you are living in a "crashing environment"
Don't know what Win CEMENT is ? Well this is said to be the latest MS OS composed of all the bugs found in Win CE, Win ME, and Win NT.
Concerning changing my code, I'm always open for suggestions. Well, I'm using VB but I'm sorry - I don't understand why you are asking for a change. Why should I display the Common Dialog Open/Save windows w/o actually using the control. To my knowledge, I'm using this dialog only when the "Load File" button is clicked, and in this case, I'll need to allow the user to select the list file to be loaded. So why should I display this dialog w/o actually using this control. Could you please be a bit more specific - thanks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
I know it may seem silly to ask, but I seem to always have either my BasicStamp or the SXKey fail to program due to low voltage.
At times I have gottem odd behavior and at other times it just says that no device can be found.
My problem is that I prefer to use a battery pack at my programing desk because more wires just get tangled. Sooner or later I find the wires pulling everything off the table and onto the floor.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
G. Herzog in Taiwan
Guenther,
I tend to be really good at finding software bugs. I should really be a beta tester. As for the computers, I'm using winXP on every machine that the software is crashing on. XP pro on two of them and XP home on the laptop. I do have win98Lite· (a·mix of win98SE and Win95) on the 4th·computer, but I don't program SX's on that one! The 5th computer also has no affiliation with SX's.·
As for the Control/Class.·SX-Sim·loads the control with the·sxsim.exe itself. (Actually,·due to the apartment model programming, it loads a copy of·the workspace·used by the·control, but this is a minor detail). If you used the control as most people do, it exists on a form (probably the main form).·It is loaded when the form is loaded. Even though the you only "use" the control when "Load File" is clicked, it is actually loaded as soon as SX-Sim starts.
This is the reason that I am having the trouble.
The Comdlg32.ocx is just a chunk of code that makes API calls in windows and tells windows·to·display all of the dialog boxes. Thes·dialog boxes are already built into windows. The Comdlg32.ocx is just a wrapper to make it a little easier to access the API calls. The API's are actually what do the work, and display the dialogs. In the case of the code example that I posted the link to, someone rewrote the functions in the .ocx and put them in a .cls file. The comdlg32.ocx can be replaced by the object class, which whill then·be compiled into the VB program. That object class·functions exactly the same as the control, however the control is never called/loaded.· The program (in·this case SX-Sim) would·never access the·Comdlg32.ocx control (It would never need to).·Any version compatability issues with Comdlg32.ocx would·go away (that I'm aware of!).
This·issue really arrises when you·distribute only the·*.exe file. The SX-Sim program·is not really a stand alone program, yet it is distributed as one. Most programmers would consider this to be poor programming practice (Please don't take offense at this, I am not diminishing the work you put into it. SX-Sim is a very nice program). Since SX-Sim·has dependencies on other controls,·removing the dependencies would truly make it a stand alone program.
Does this make sense?
-Dan
FYI, Ever wonder why the comdlg32.ocx displays different dialogs depending on the OS? That's because the OS actually has the dialogs, and the control just calls them up.
Post Edited (dkemppai) : 7/29/2005 11:30:45 PM GMT
I'm convinced that the program·just doesn't like my hardware serial port!·
-Dan
·
thanks for the detaillied explanations in the Comdlg32 matter. Sorry, somehow I missed the link you had added to your previous post. In the meantime, I had a close look at it, and I must admit that this presents an interesting (better) alternative to the default Load File dialog.
I'm pretty sure that I'll implement this in the next version of SXSim in order to get rid of the "Comdlg32.ocx not found" problem.
Peter and I are currently testing another method of integrating SXSim and the SX-Key IDE, so it may take some more time to get a new release of SXSim out of the door, so please stay tuned.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
I'd be curious to hear what the changes would involve. Please keep me posted on your progress.
Thanks,
Dan
Given that you have problems with walking on three different computers (and given that thousands of users use the exact same software you have without problems), lets take a look at what is common to your setups. Each time you are using the same SxKey, and the same project it's attached to. As someone else mentioned, power supply issues have proven to be a bit of a problem for some. I know that say the power supply is good, but have you swapped it out with an alternate and beefier supply to verify this, or are you just assuming it's good because it has always worked in the past?
It's also possible that your SxKey is damaged in some fashion. The best case here would be to contact tech support and request a swap to verify that the key is or is not your problem.
Of course, it's also possible that the IDE software is screwy. My only reason for getting to it last is that given that yours is the first complaint I've heard regarding "walking", it hard to say if the problem is the IDE software or something specific to your setup. Now then, it may be that most people don't use the "walk" feature and hence the lack of complaints, but I really have no idea how often the "walk" feature is used by people.
The mighty FIFO settings have also been a cause of some problems for some users. Setting them from the defaults down to something small like 2/4 or 4/6 has helped many people.
As for the debugger getting large fonts, that is a problem that I have seen myself, but the problem is that it's so rare that I have been unable to come up with a case that consistently causes it to happen. As you know, without the ability to replicate a problem, I am pretty much just taking random guesses to try and figure out why the problem occurs. If the problem happened more often, I might have a better shot at finding out the root cause, but it is a very infrequent event for me.
Thanks, PeterM
To clarify, I am having different sets of of troubles on different computers. I am currently using three different computers to program the SX with two different SX-Keys (I have a third SX-Key that I have not taken out of the box yet!). The computers that I am using are·my work PC (An older AMD CPU based computer), my personal laptop (9 month old Toshiba laptop) and and my personal PC (AthalonXP based computer).
I am doing a lot of programming (~12 hours per day), so finding problems does not surprise me.
As for the trouble with each computer, I have two major probelms on my home PC.·First, The·SX-Key will not operate on my hardware serial port when walking, no matter·what the FIFO settings are set at. The only way I can get the SX-Key to operate reliablily is to use an external USB to Serial converter. Walking works as expected, but very slowly (probably due to the 16mS timeout latency timer in the FTDI USB to Serial converter).
The Second issue on my home PC is that the·Comdlg32.ocx file·required by SX-Sim is not installed·during the SX-Sim install. This causes the SX-Sim software to crash EVERY SINGLE TIME that I start the program. This is annoying to say the least. This issue however,·is·well understood by both myself and Guenther.
On my laptop, the SX-Key software crashed during the first time that I ran the software. This crash terminated with the error "List out of bounds (-1)". I believe that this was caused by the SX-Key software trying to interrogate my modem, and failing. (I would have expected to recieve the error message "SX-Key Not found on Com X" rather than a crash. I did finally figure that one out.
As for my work PC, I have crashes on Assembly, I have the large font at times, and the SX-Key refuses to program the SX-Chip at times. I believe that I have isolated the trouble programming to a bad connector on the SX-Key (The 4 pin header, of which I need a new one!). The large font issue is something that you are aware of, and I have no idea what causes the software to crash on running Assemble. Although, I believe that the crashing on ASM is caused by me hitting the assemble button when running (I know, I know, all of the buttons are supposed to be·be disabled when running, but I believe they are not allways disabled when they should be.)
As for the power supply, I have three different power supplies (Each different models). I have also monitored the·supply voltages, and found the·lowest voltage level to be·4.925 volts, lasting for about·~150 micro seconds. (I'm·very sure that·it's not my power supplies.)
I understand·the difficulty of debugging the·'large font' issue. I do enough programming to know that there·will·always be a·bug that will be near impossible to find. You are correct that it·is a rare occurence, and so, it doens't bother me. My reason·for posting it was to be·sure that you were aware of it.
Overall, I'm happy with the software. The probelms are just a bunch of little issues that are adding up and driving me nuts. (With execpton to the SX-Sim crashing on my home PC, which has forced me to use my laptop until that issue can be resolved.)
Feel free to contact me about any of these issues. I would be more than happy to discuss them with you.
Thanks,
Dan
·
·· Just wanted to chime in and say that you can change the latency in the Advanced Port settings for the FTDI USB to Serial Adapter.· In fact, on my laptops, such as my IBM ThinkPad, you have to for proper functionality.· This may increase your speed, somewhat, when using that adapter.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
Thanks for the tip! I'll have to look into it. I don't really use the FTDI VCP drivers all that often, most of my experience is with the·Direct Drivers and manually seting the·values in software.
Thanks,
-Dan
1 - Can you can give me the specs on your computer (CPU speed, ram, that sort of thing)
2 - Are you plugging the SXKey directly into the SxTech board or are you extending the four leads from the board to the SXKey?
3 - What else is running on your machine when you are using the SxKey? CD player? Winamp? Browser? Other software?
Thanks, PeterM
Peter,
I am programming an SX52 on my own circuit board. Lead lengths are much·shorter than the SX-Tech board. Good ceramic bypassing caps are used for the SX52 and 220uF·Panasonic FC Electrolytics are used for bulk filtering of the incoming DC. I guess, the important·detail is that the same board can be programmed on one computer and not the other.
The computer that I am having the most trouble with is an MSI motherboard, running an AMD AthlonXP2400+ CPU, 1024Mb Ram (300mb FSB Dual CH DDR), GFX5200 Video, Raid SATA drives and WinXP Pro SP1. Swap file is turned off, with ~700Mb free ram. Standard CD-RW and CD drives. No additional hardware. Everything is very snappy, and no spyware, viruses or Trojans are resident (At least none that my·scanners can find!).
No other software is running, Other than the standard windows processes·and a couple of very small tray item programs ( Netrun, Atomic Time Sync, and a Remote Disconnection Server. These have all proven to be reliable on the system).··I have shutdown most of the·unnecessary Win processes, including the ones with security issues. I'm not running a real-time Virus scanner (I run it manually). For testing thing, I have even killed off·the unnecessary processes, including my Tray progs and all but the critical windows processes. This computer is a very lean, mean number crunching machine. I use it for·very CPU intensive calculations (such as·calculating PI to a billion places).
The other computers are:
1. A Toshiba M35X-S149 laptop (With unnecessary progrma/processes shut down or uninstalled).·
2. A MSI based 1200Mhz Athlon with all of the basics (Nothing special)
Hope this helps. If you need more info, let me know!
-Dan
Thanks for the detailed info. Unfortunately, I'm still in the stumped department on this one. I was hoping you'd throw me some kind of bone, like, "Oh, I have a 386-33 with 2MB of RAM running Windows XP." You know, something easy for me. You are definitely doing all the right stuff with regards to this machine.
I do know that something changed between Win2K and WinXP with regards to the way the OS handles the serial port. What changed? Not a clue, but virtually all the problems with the SxKey and serial communications come from folks running WinXP. The SxKey is very sensitive about expecting a steady stream of communication, even when it's just sitting idle. It has a pretty short timeout period built in to it. I believe the idea is to keep the SxKey responsive when there is a timeout.
My personal opinion is that somehow MS gave the serial port lower priority in WinXP, causing momentary data hiccups which cause timeouts. This line of reasoning is how I discovered that lowering the FIFO settings helped. With a large FIFO, the serial chip waits until the buffer is full before notifying the OS that it's ready for more data. This is fine when you have more data to send than the size of the FIFO as you're always filling it completely. However, when you go below that threshold, the serial chip has a timeout built into it that tells it to go ahead and notify the OS even though it's below the FIFO setting. Lowering or eliminating the FIFO reduces or removes this time delay, resulting in smoother data delivery.
The hardest thing about trying to fix these problems remotely is that I have a completely different setup than you which doesn't exhibit any of these behaviors. Here's a long shot - is there any way for you to send me a working version of your PCB that exhibits this behavior? It would be returned, of course. I would also need some bit of software, it could be as simple as toggling an LED, as long as it causes your machine to barf when walking. I know this may be impossible, but short of you sending me your computer, I don't know how much closer I can get to replicating your problem. If this is not possible, I understand, but it seems to me that if three different machines with different serial ports and OS versions all have the same problem, then the least common denominator is either your key or your board. I would love to be able to find out if I'm barking up the wrong tree or not.
Thanks, PeterM
Not all of the computers show the communications problem. Only one of them has the trouble. And, that is only with the Hardware Serial. I find this just too weird. I'm in the process of searching for a PCI Serial card for that computer. If I can find one easily, I'll put that in and try it again.
Anyway, I may be able to send you a board. It will take me a while to get one built up, and I do have to finish the code for my customer first.
How about this! Do you think that between you, myself and Parallax we could build a USB version of the SX-Key? I've been thinking of some relativley simple improvements, that would really make this thing nice. Anyway, I· can do the hardware/circuit board design. If someone with access to the SX-Key source code (SX and PC side) were willing to work with me, it could be relativley painless.
Anyway, food for thought!
-Dan
·
I'm pretty sure there was a thread quite a few months back regarding a USB version of the SxKey, and my recollection is that Parallax decided not to pursue it. However, it's unclear to me that a USB version of the key would really do anything different for you. All the COM calls in the SXKey are raw, Windows API calls - there is no library or additional overhead involved. Given the simple nature of serial ports and whatever problem you are having, it seems unclear to me that going to a more complicated interface (USB) would guarantee success, despite the fact that a USB based serial port is working for you on one of your setups.
Thanks, PeterM