Q LOGIC PROGRAMMING INTERFACE

[WheelieMan]

Would any of the driver downloads on this page be correct?

http://www.sontheim-industrie-elektroni ... enter.html

Like perhaps the MT-API?

[vinsen]

For the CAN cable in the program CURTIS 1314-4402 ! Is your driver CAN .

[WheelieMan]

I do not know how to check the driver from the program, but the only type of port that shows up in the program is USB. I am running version 3.12 of the 1314 program so I guess it is possible I need the update. I have checked for updates within the program but it does not find any that are available.

My computer does now at least recognize my chair as a CANUSB device. I installed the entire MT API program, but I read somewhere on this site that portions of it can interfere with the 1314 program. As far as I can tell, I uninstalled all of that program but the pertinent drivers.

[rover220]

I have access to the full oem 1314 programming station and should be able to sort for those that need.

[rover220]

It is a CAN BUS cable. I do not see a lead number (or I do not know where to look/check). Here is all of the writing I see on it:

photo-1.jpg

photo-2.jpg

Both the socket on my chair and the cable are five pin connections. I am trying to program a QLogic controller that uses an enhanced display. The chair is a Q6 Edge. I am trying to program the chair to use the built-in Bluetooth as a mouse and possibly to connect to my iPhone/iPad.

This is an older cable. From what i remember this will only work on enable 40 systems.

[woodygb]

Isn't the Enable40 a serial interface protocol rather than CAN ?

[rover220]

It is but you can use that cable by changing the required setting in the 1314 programming software.

[woodygb]

I didn't think that Sontheims Can Bus light had serial pins just Can low ,Can high and ground.

[rover220]

I didn't think that Sontheims Can Bus light had serial pins just Can low ,Can high and ground.

im not an electronics expert however i have that same lead (and the newer one) and it will 100% work on enable 40 once the settings in 1314 have been set correctly.

[woodygb]

and it will 100% work on enable 40 once the settings in 1314 have been set correctly.

and these settings are?

Note that I do NOT know if the Enable40 uses a CAN or Serial communications protocol for programming ...the Enable40's PDF/Manual was as I recall ambiguous on this point ..but the 5 pin plug picture is notated TX RX rather than Can H / Can L .

rxtx enable.jpg (63.19 KiB) Viewed 13598 times

[rover220]

[woodygb]

You have chosen the top pic ...a CANfox interface ...rather than the 2nd pic CANUSBlight ... did you mean to do that?

http://www.sontheim-industrie-elektroni ... fox_EN.pdf

http://www.sontheim-industrie-elektroni ... ght_EN.pdf

[rover220]

You have chosen the top pic ...a CANfox interface ...rather than the 2nd pic CANUSBlight ... did you mean to do that?

http://www.sontheim-industrie-elektroni ... fox_EN.pdf

http://www.sontheim-industrie-elektroni ... ght_EN.pdf

you are indeed correct. seems ive got things abit backwards however i have tried today and the earlier lead will work on an enable 40 chair. i tried on an otto bock skippi. whether the otto bock leads/software is any different to q-logic i cant be sure.

[woodygb]

Your also appear to be using the latest 1314 Software rather than the earlier version ... which WheelieMan probably has.

EDIT .. The earlier version hasn't got a pictorial choice of interface.

[rover220]

Your also appear to be using the latest 1314 Software rather than the earlier version ... which WheelieMan probably has.

it is indeed the latest version.

[woodygb]

@ WheelieMan ...It might be worth obtaining the later software version...
Both versions co-exist happily on my computer...
In fact I have 3 installed versions ...the odd one out is the "non existent" Pride version that requires a dongle of some sort.

dongle.jpg (10.59 KiB) Viewed 13443 times

[RoyOnWheels]

Would any of the driver downloads on this page be correct?

http://www.sontheim-industrie-elektroni ... enter.html

Like perhaps the MT-API?

I have the CANUSBlight pictured earlier and the MT-API driver looks right.

Does anyone have a login to download it?

[woodygb]

I have a login.

I can send you the MT_API_V7.04.3400_4Handle.zip file.

Private message me you email address.

BUT ... I believe that Curtis uses a "private build" version.

[davidpaul]

I'm sorry but I'm going to be a pain, I have already made a "cable" and have a program on my laptop to access and change the settings on my pilot + controller. Today we have brought a quantum 600 sport for my son with the q-logic controller, as I find it difficult to read through a load of post's to find the info I need. Can you tell me what I need to make the "cable" to connect controller to laptop, we can deal with the other bit at a later date. Thanks

[woodygb]

Start at page 1 of this thread and read until page 2.

Should you wish one of the Chinese CAN USB's let me know... as I have one doing nothing

[woodygb]

To simplify it greatly .

You need the 1314 software with some additional / modified files ... plus the Chinese QM USB-CAN A1 and two wires.

[davidpaul]

Ok thanks, yes I would like that usb you have spare, do you have paypal ? so I can pay you

[woodygb]

Sure ...

P.M. me your address and I'll post it off to you.... pay me when it's proved to be functional as I've never tried it ... other than plugging it into a USB port.

[davidpaul]

Pm sent, thank you

[davidpaul]

Hello, I've sorted my interface and the program is all up and running with a lot of help from Woody, but we have come up against a problem.

I can connect to the controller and change things like lights and stuff, view the fault page but I can't get into the powerbase, It will start to load and then stop.

it starts with "reading device menu" then after a few seconds or sometimes a bit longer I get the "reading menu entry failed" message.

Does anyone have any ideas ?

[davidpaul]

Would it help if I said please ?

[falco peregrinus]

Would it help if I said please ?

Dunno. I've never tried that. I normally just swear at the things. Can't say it works very well, and it does upset the neighbours a bit, but I've been using that technique for forty years or more now and it's become an instinctive response.
Falco.

[falco peregrinus]

Seriously this time. Just speaking from long experience with computers, it sounds to me like data corruption, possibly caused by failure of a memory chip. It seems to me that you can read some data correctly, no problems, but other data won't read, and the obvious two differences between those two situations is (1) different data, and (2) the data is stored in a different place. In the case of "different data", this translates to data corruption, and the software trying to read it detects that the data is corrupted because of the CRC (cyclic reduncancy check) method that is commonly used in such situations so that a program reading the data knows whether it has correctly read the data or has read garbage. In the case of "data stored in a different place", we're talking about different locations in memory, which translates to failure of a memory chip in this instance (seems how I would assume that the memory chips are soldered to the PCB and are not plug-in to socket types, therefore bad connection is not a possible explanation.)

What can you do about it? Well, the easiest way to test which of the two alternatives is the explanation is to load fresh data into the same memory locations. Ie, create a new-from-scratch configuration file and upload it to the controller. If the memory chips are ok, the upload will work. If the memory chips are not ok, the upload may or may not appear to work, but probably won't work and will tell you that it didn't work, because I would expect the upload algorithym to verify the transferred data before declaring the upload complete, but it may not, depending upon how experienced and intelligent the programmer who wrote the code is. Having achieved what appears to be a successful upload, try changing things in the configuration again, and try a download. If no problems, then it was just data corruption, possibly caused by a memory chip with an intermittent fault, but also quite possibly caused by an electrical or electro-magnetic event that may or may not ever happen again.

Actually, that gives me an idea. Before doing anything, try downloading the configuration from the controller to your PC. Given the problems you have had, I would expect the download to fail (with CRC or read errors), but if it works, that's good, because then you can take a look at the data on the PC instead of on the controller, and you'll have a copy of it on your PC. I doubt if it will work, though.

Upon rereading your post explaining your latest difficulties, a third possible explanation comes to mind. If the software version you were using to read the controller is not fully compatible with the firmware on that controller, that too could cause your present problems. Such a situation could arise if you were using generic software on your PC but the wheelchair manufacturer had installed custom firmware on the controller that would only talk correctly with similarly-customised software on the PC. For example, I've heard that Pride customise their latest controllers so that you need a Pride version of the programming software in order to program their controllers. If that was the case, then you may be able to solve the problems by uploading generic firmware to the controller to match the generic PC software - but how you do that I don't know. I'll guarantee that it can be done, though. Nobody these days is going to build computer-based equipment that they can't upload fresh firmware to in case they accidentally release a product that has bugs in the firmware.

Again, after yet another reread of your latest difficulties, I'm puzzled by "reading device menu". Clearly it times out on it's attempt to read whatever it is that it is trying to read, which supports my three proposed explanations, but why does it call it "device menu"? If it was encountering a security flag that was preventing it reading somewhere that it wasn't authorised to read (eg, using dealer version software to read something that required OEM version software), then I wouldn't expect it to time out. Rather, I would expect a fast response with an error message - perhaps a meaningful one that can reasonably be understood to mean that you were using software not authorised to do what you are trying to do, or alternatively a nonsense message intended to leave you none the wiser as to the true reason the read failed - but if it was a security flat, I would expect a fast response of some nature, NOT a delay before error message caused by the retries timing out. So I don't think it is a security flag problem.

So why does it say "device menu?" Does anybody know? Can anyone throw some light on that? Is this something specific to this product, with special meaning that I am unaware of?

Falco

[gologen]

I can connect to the controller and change things like lights and stuff, view the fault page but I can't get into the powerbase, It will start to load and then stop.
it starts with "reading device menu" then after a few seconds or sometimes a bit longer I get the "reading menu entry failed" message.
Does anyone have any ideas ?

Powerbase has much more data to download and USB-CAN converter or PC gets error at transfer time.

Did you try what i said at PM?
1. Don't use long wires for connection to controller and twist their.
2. Check jumper on the USB-CAN converter.
3. Try computer with Windows 7 or Windows 8. I have had similar problem with winXP. But never with win7 and win8. Also, possible, it depends on the power of the computer or USB speed. I had old computer with winXP and newest with win8.

[falco peregrinus]

Gologen raises an important possibility that I overlooked. If the cable is defective in any way - eg, unshielded, poor connection at plug, poor condition wire - then that too could cause your problems. A bigger data download means that there is more time in which a communication error (causing retries) can develop than there is during a small data download. For example, gravity moves the cable a tiny bit and creates a bad connection. By "unshielded" I mean a cable in which either there is no metal mesh surrounding the data-carrying wires, or there is a metal mesh surrounding the data-carrying wires but it is not connected to ground/ earth. And the longer the wire, the greater the voltage drop in the signal that represents data. Every data communications protocol has a rated cable length, but the rated cable length assumes perfect condition cable, and any defects in the cable result in voltage drop, which can result in data loss, or simply voltage at the other end of the cable which is below spec, and thus unreadable by the chips trying to interpret the data. (Because of chip variation, sometimes one device with one type of chip will work fine with a cable that another device with a different type of communication chip will not.)
Anyway, the short version of all this waffle is that the problem could simply be your cable.
Falco