CA-42 Com port issues - Commonfx.sys

So installed CA-42 cable, wont connect to phone or come up "enhancement not supported" even,
However have found that when I go to nokia connection manager to set the com port it comes up as....commonfx.sys....which is a file used by my sound card....odd
Any ideas on ways to solve this issue?
Using Windows XP SP3

What phone do you have? Nokia PCSuite includes all the USB drivers you need. Uninstall PCSuite and all the related Nokia drivers. Reinstall the latest version of PCSuite. Open PCSuite and then connect the phone using a compatible cable. When the phone prompts you, use the PCSuite tab. Now, have fun.
‡Thank you for hitting the Blue/Green Star button‡
N8-00 RM 596 V:111.030.0609; E71-1(05) RM 346 V: 500.21.009

Similar Messages

GPS Error on F3507g & Windows 7 "The GPS NMEA COM Port is not available" x200

I have an X200 with a WWAN Card 43R153 (Ericsson F3507g) running Window 7.
The WWAN reliably connects to Vodafone but I can't get the GPS to work.
Device manager shows this port Enabled:-
Ericsson E3507G Mobile Broadband MiniCard GPS Port (Com8)
Driver Invogps.sys from Ericsson AB, Version 1.0.0.28 29/09/2008.
Thinkvantage GPS version 2.50 is also installed and Lenovo System Update says everything is up to date.
When I "Turn on GPS" or run 'Lenovs GPS" I get this message:-
The GPS NMEA COM port is not available. You need to check the following things.
- Another GPS application is using the COM port.
- COM ports is disabled. You can enable the COM port in the Device Manager.
Location and Other Sensors shows nothing installed.
I've tried deleting all the drivers and reinstalling but not luck.
Has anyone else had the same problem and found a solution. I can't think of anything else to try.
ThinkPad X200 7459-1P0

If you are running a Windows 7 Weather Gadget on your desktop, try shutting it down entirely and see if that changes your GPS "in use" problem.
Cheers,
Bill
I don't work for Lenovo

Any known 'porting' issues between 8.2.2 and 9.0 ??

Hi all,
we are in the process of evaluating LS ES2 (9.0) and would like to know if there are any 'porting' issues between the two versions. Asked another way, are there any issues in deploying a 8.2.2. LCA onto 9.0 ?
Dan

8.2 LCA's will run fine in 9.0 if they are just deployed into it. But in 9.0 a new application model has been introduced, so in order to make changes to anything after you've migrated it you'll need to create an application and migrate your processes and resources into it. You may want to take a look at the Leveraging Legacy Solution document available online. Here's the link: http://help.adobe.com/en_US/livecycle/9.0/workbenchHelp/help.htm?content=leveragingLegacy. html .
Chris

HyperTerminal sees a COM port but VISA does not

It should not be possible that HyperTerminal sees a COM port but VISA does not. Does anyone know why or have any ideas?
Here's some more info: I wrote a LabView (LV) program and deployed it (via the Application Builder) to some of our production department's PCs (some Windows XP and some Windows 7). We use it to set up products we design and manufacture through our device's USB serial port. The USB port is actually a virtual COM port (VCP) - a USB to Serial converter or "bridge". We have a custom driver for our device and since each device's USB bridge chip is programmed with a different serial number, every time we connect a new device to the PC the installer runs and assigns a new COM port number. This is so our customers can use multiple devices on a PC. Fine. On one of our production PC's we were close to COM900 ports (HyperTerminal sees only up to COM256) when suddenly Win7 would not allow any more. We were able to uninstall orphaned (non-present) COM ports from DeviceManager ("DM") by starting it from a command console (DOS window) with a special command-line switch, "set devmgr_show_nonpresent_devices=1" then "start devmgmt.msc" (I have this in a batch file). In DM View menu you can "Show hidden devices" and uninstall them as if they were connected. I've also tried uninstalling them the normal way when the device was actually connected. Either way, sometimes, not always, depending on the COM port number, after reusing that port number by installing a new device which picks up that old, freed-up number, LV VISA doesn't see it. In other words, when "Refresh" is clicked in the COM port VISA list box, any new devices installed should be and normally are seen. (Refresh is not needed if the application is started after the device's driver is installed. It is only need if the LV application is open with the new device is added.) However, HyperTerminal does see it and lists it in the Properties screen, the "Connect using..." list box. And the port works with HyperTerminal. (Of course we've tried rebooting after uninstalling and/or reinstalling the device, with the same results.)
When I've spoken to the NI Applications Engineers in the past about serial port issues (not about this problem) they have confirmed that if HyperTerminal can see the port then NI VISA should also see it. This is crazy. I am posting this in hope that someone can shed some light on this problem.
Thank you. -Ed

Good catch. Yes, we're using the Silicon Labs CP2102 and have created a "custom driver" installation package. Our new PCBs have a factory-programmed chip, so the PC reuses that COM port (COM3 on that PC). The problem is when we we re-program the CP2102 (setIDs exe) with our PID, and device strings (including the S/N), the PC runs our installer and assigns the next COM port number. I was hoping that maybe it would go up to 64K or something! Anyway, it surpassed COM256 but we ran into this problem when almost up to COM900.)
There is a registry entry for each SN device, which shows the assigned port. If we delete the key with regedit, the COM port database (don't know the file name) still has the port number. That's where Device Manager comes in. It seems to allow us to manually delete the ports, but it would take quite a while to delete 900. (I was trying to make a batch file for DevCon, but couldn't get it to see the HW ID of the devices in need of deletion.) So we tried manually deleting a few. After doing that Device Manager shows that Windows (and HyperTerminal) can reuse the port number when a new device (new SN) is installed, but, as you know from this post, VISA cannot see unless I manually add it in MAX.
I can't see how it has anything to do with the Silicon Labs driver. I might have to delete ALL of MY devices, then uninstall the driver files, reboot, then reinstall, as you suggested with the SiLabs driver. However, I don't see how VISA will now see these changes. VISA must have it's own database. That's what I thought deleting the ports in MAX would clear out, like a fresh install, but apparently not.
I've been through Silicon Labs' tech support on other issues and they've been able to help on some. I could run this by them.
BTW, have you noticed that Silicon Labs' chip and driver, while faster than NI's own "bridge" or serial-USB converter (I returned it because at $100 it's performance was worse than a $20 converter you can buy in Staples), is substantially slower than a real serial port? For example, our device can transmit 250 readings per second (a 12 byte string). A real serial port used with my LabView program can keep up, i.e.., graph & tabulate at that rate, but with a VCP we only get about 70 RPS. Same code. Can't figure this one out. They say the've tested the driver to 900 KB claimed. We're using 115KB here. Anyway, the VCP driver makes it look like a COM port which LV thinks it is. Why is it slower than a real port when the USB should be able to work almost 10 times faster than I'm using it (up to 1024 bytes per mSec per the full-speed USB spec, which SiLabs claims they verified)?
Anyway, I appreciate your help. Thanks! -Ed

Can the Com port on the EX90 be connecting to an AMX NI700 to receive command?

if so, what are the pinouts for the EX90? (TX/RX/GND) The AMX uses pin 3 for TX, Pin 2 for RX and Pin 5 for GND. I have been using an RJ45 cable and trying to match pins but I am still not getting a TX signal. Also, does the COM port need to be enabled?

The EX90 is not really build to be controlled by an additional control system.
(in general thats a thing for the integrator prodcucts).
The Serial port is not a RS232 (+/-25 Volt), instead of their using TTL level.
So a direct connection without a proper cable might cause a hardware fault!
I think the serial port was on by default, but that might have changed on the current software versions, thats what works fine for me:
xconf // serial
*c xConfiguration SerialPort BaudRate: 38400
*c xConfiguration SerialPort LoginRequired: Off
*c xConfiguration SerialPort Mode: On
The serial port is also on the bottom of the device, its ok to use it if you need to
troubleshoot boot issues, but besides that not really usable.
Dont expect Cisco to do any support for this if you run in to strange behavior when
controling the system with a 3rd party control.
Btw, what I would strongly recommenced is to use the telnet/ssh cli or http(s) API.
could picture that this might work with the AMX700, so why even think of using a serial port, ...

VISA "Find" not seeing COM port but Win7 sees it

Allo. I'm trying to communicate via virtual com ports with a device with an FTDI chip. The device with the FTDI chip has both a USB type B port as well as a 9 pin dsub port, and I need to verify both ports work.
I'm using a laptop with Windows 7 and my program is in LV 2010. I have a Sabrent USB to serial cable to test the dsub port, and a standard USB cable to test the other port. I've installed the latest FTDI drivers and when I plug in both cables and look under Windows Device Manager, I will see both of them under unique COM port settings (usually COM4 and COM 5). So Windows sees and recognizes both virtual COM ports, and no yellow warnings.
However when I run the "VISA Find" function in LabView, it only sees COM5 (the Sabrent serial cable) but not the COM port using the USB type B cable. I send the results of the "VISA find" to a display and it will show other ports, like the parallel port, so I know it's seeing more than one port.
Any ideas why Windows can see the two COM ports but the "VISA Find" function can only see one? My guess is there's something with the FTDI driver set up.
Amateur programmer for over 10 years!

Yes, but its not for the faint of heart!
You can probably do what you want by using the refresh "F5" in MAX or add this token
[VISA-CONFIG]
ShowRegisteredDevOnly = 0
to C:\ProgramData\National Instruments\NIvisa\visaconfig.ini
Another thing to try is to recover the unused COM Port numbers each time you change the device. By default Windows will "Save" those previously connected COM port numbers an if it sees the device again it will re-assign the old number. This means that the COM number keeps getting larger and larger. At some point the PC's BIOS will say that's rediculous and you will experience trouble.
Programatically you could call
C:\Program Files\National Instruments\NI-Serial\NiPortConfig.exe to launch the same utility. there is probably even and unpublished switch to click just that one big button for you but I can't find it.
It looks like you may be running into some part of this known issue
Jeff

Not enough memory error when disconnecting device on a virtual com port

I maintain a large application that collects data from many data source channels (using coustom hardware read thru a conventional COM port) and I am adding a GPS data source on a USB port using a virtual COM port driver. The application runs 24/7/365 and works well including the GPS data, if undisturbed. However, the application needs to tolerate a physical disconnect and reconnect of the GPS device without user intervention. When I disconnect the GPS, the application becomes unresponsive most of the time (the mouse responds and other programs that are open on the desktop work fine). I abstracted the serial code and made a separate vi (below) for testing. When I disconnect the GPS from the COM port, I get a "Not enough memory to complete this operation" message 9 out of 10 times and the vi is unresponsive until I clear the error message (the tenth time it continues working). I built the vi this way to collect data continuously. I suspect that this is the problem with the full app but I don't see the Not enough memory message there and therefore the full app does not respond and must be terminated via Task Manager. The full app runs full screen mode.
The LV app runs on Windows XP and LabView 7.0 (the client doesn't want to upgrade).
I have tried probing the error message lines at all points in the vi but they don't show anything when the 'Not enough memory' message occurs (they show the expected device not found error after clearing the error message).
Any suggestions would be greatly appreciated,
Mel
Still learning LV......
Please post any code suggestions as graphics as I don't have access to any version of LabView newer than 7.0.
Attachments:
SerialPortRead.png ‏22 KB

Jeff·Þ·Bohrer wrote:
First, there likley WAS human intervention that caused the GPS device to be removed. That wont happen when you lock the device inside a cabinet with the rest of the test system. Physical access control first! If someone goes and mucks with your experiment setup while its running, that's a "poor Labratory procedure" not a "new software requirement"
I think he was meaning to say without user intervention on the software side.
I have seen odd behavior if you disconnect from a com port whilst LV still has the port open. There are a couple things I myself woud try, being the experimenting type that I am. Perhaps setting up a com port check to see if it has a valid connection before polling for data. If not then a blank case or some other generic code.
The issue with this would be if it became disconnected while LV was polling data. Hard to get around this condition. Is there a way that the cause of the of the connect/disconnect (whether human or otherwise) could be set up so that a signal can be sent to the controlling system (pre-disconnect and post-connect) to trigger an event to handle the software side? A simple signal switch or something. Just thinking out loud. Withoug knowing all the particulars, it's hard to make detailed recommendations.
Doug
"My only wish is that I am capable of learning each and every day until my last breath."

No Bluetooth COM port with Version 6.5.1.4500 (T530, Win7 64bit)

Hi all,
after installing the current bluetooth drivers for the T530 (I'm not sure which drivers were installed before - I think standard Windows 7 drivers), I have several nice additional bluetooth profiles supported, by the virtual Bluetooth COM port has disappeared .... und uninstall is not offered by the drivers' setup.exe.
Does anyone have an idea how to get the COM port back?
Thanks for help,
Mark123

Hi,
I would like to know is there any update about the issue. If the issue is solved, will you please share the resolution here to help others in this forum who encounter similar issue.
Regards,
Yan Li
Please remember to mark the replies as answers if they help and unmark them if they provide no help.

Using VISA can not find the com port

I use visa read but can't find any com port in Windows 7.
How can i find the com port in Windows 7??
由 jw2002 在 06-28-2009 09:20 AM
上編輯的訊息
由 jw2002 在 06-28-2009 09:20 AM
上編輯的訊息
Solved!
Go to Solution.

Windows 7 is not officially supported by National Instruments as it hasn't even been released. That means you won't get any official support from NI on this.
That said, does your computer actually recognize a serial port? Do you have an actual serial port, or do you have some sort of virtual COM port, or are you using some sort of adapter, such as a USB to serial port box? If it's any of the latter, the most likely reason is a driver issue which needs to be written to be compatible with Windows 7.

The LV crashed when I call a dll to control my com port

I am controlling the com port with calling a dll(dwdio.dll--see the attachment). The VI I used is also attached below.
I just used four functions of this dwdio.dll, as followings:
1. bool DWD_set_comport(unsigned char com_port,int *handle)
Parameter config:return type--unsigned 8-bit int(value),com_port --unsigned 8-bit int(value),handle--signed 32-bit int(point to value)
bool DWD_set_baud_rate(int baud,int *handle)
Parameter config:return type--unsigned 8-bit int(value),baud--signed 32-bit int(value),handle--signed 32-bit int(value)
bool DWD_check_comm_link(int *handle)
Parameter config:return type--unsigned 8-bit int(value),handle--signed 32-bit int(value)
bool DWD_close_com_port(int *handle)
Parameter config:return type--unsigned 8-bit int(value),handle--signed 32-bit int(value)
I can run my vi successfully,but Labview will crashed when I close Labview application. I tried many ways to change the parameters and convention, but there is no effect.
Because this dll file need hardware dongle,so I can't upload the vi. I just attached the screen-shot of it.
Can anybody have some analysis on my vi to give me some valuable suggestion?
Attachments:
dwdio & explanation &my vi.zip ‏2456 KB

Yaoming wrote:
> SVences,<br><br>I know that Erroneous data types assignments can cause crashes.
> I have checked all the data type with my experience and knowledge,but I didn't
> find anything should cause this crash problem.<br><br>After all,I am not very
> experienced in Call Library Function, so maybe my vi still have some erroneous
> data type assignments. Can any DLL expert help me to locate them?
> For the original function description, I have posted as attachment in the first
> post. Therefore,anybody who want to check my data type error can have a check
> with that function description.
> That issue is very urgent and important to me. Can anybody to help me sort
> this problem as soon as possible? Thanks in advance.
A few remarks:
1) the Bool return value is probably an int. It doesn't look like a
standard Widnows datatype so you will have to look in the documentation.
However this is unlikely to crash your code.
2) The handle parameter for DWD_set_comport should be set as Pass:
Pointer to Value. All other parameters should be passed by Value only as
they are not pointers at all. Also please wire a 0 constant to the right
side of the CLN for that parameter to provide memory for the DLL to
write in.
3) The calling convention for the DLL functions is not obvious from your
documentation. You have the choice between C (cdecl) and WINAPI
(stdcall) on Windows. Since this DLL seems to be available for multiple
platforms (The remark for each function) it may be that the developer
decided to use cdecl calling convention (a smart choice I would say) but
Windows DLLs usually use stdcall instead.
Having the wrong one will absolutely crash LabVIEW but usually at the
moment you return from the functioncall and not later on.
So I would guess the most probable cause is number 2, but don't discount
the other ones completely.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Is 10.9.4 having USB port issues?

Is 10.9.4 having USB port issues? I'm noticing copying files to USB ports on my Mac Pro (the front two anyway) seems to be like molasses and give me the pinwheel of death.
Anyone?

Try resetting SMC.
Reset SMC. http://support.apple.com/kb/HT3964
Choose the appropriate method.
"Resetting SMC on portables with a battery you should not remove on your own".

USB COM port read garbage Bytes

We have configured USB COM port at 625000 baud rate and reading the data continously. When the COM port is read for long time, see some garbage bytes inbetween valid data. Could somebody help what could be the problem?

1m is a trivial length, doubt that causing any problem. I am a little suspicious of the USB-Serial adapter. With an "old school" serial port it was generally hardware until the OS read the buffers where the incoming data was being "stored". Not sure with the USB version, suspect that there is little hardware buffering, and with anything in a non-realtime OS (Windows) a interrupt that puts the USB task in a lower priority and you could have and issue, although figure it would drop data rather than add it.
--- Pondering ---
Putnam
Certified LabVIEW Developer
Senior Test Engineer
Currently using LV 6.1-LabVIEW 2012, RT8.5
LabVIEW Champion

VISA unable to communicate with or see RS232 serial com port

I have a Dell Optiplex GX260 which has recently had Windows XP (Service Pack 2) re-installed on it. National Instruments VISA is unable to communicate with the single RS232 serial com port on the computer. Neither the "VISA Resource Name" control in LabVIEW 8.5 nor the "Measurement and Automation Explorer" can see the serial port. Refreshing the list does not help. "HyperTerminal"is able to both see and communicate with instruments connected to the serial port. In Windows "Device Manager, the serialport appear in the list of hardware without any warnings.
Can anyone please help with suggestions as to how I may be able to get VISA in LabVIEW to 8.5 to see and communicate with the serial port?
System Details:
Dell Optiplex GX260 (One RS232 serial port)
Windows XP Home Edition Service Pack 2
LabVIEW 8.5
Solved!
Go to Solution.

AKA_TG wrote:
Just passing by but I gotta say
Guyts who answer like that do really irritate me
Someone oughta apologize to the porr guy trying to get some help here.
Go ahead and put me on your ignore list please!
First, there is a plethora of messages on this forum and a plethora of information in the NI KnowledgeBase. If someone doesn't make the simple effort to take 5 minutes to perform a search what does that say? The issue being raised has come up, literally, dozens of times. Do you like answering the same question over and over and over and over and over again?
Second, my feelings are not unique. You will find that the irritation of people not bothering to do a simple search is shared by most of the regulars here. Why do you think search engines are available? Just so that ads can be sold?
Third, posting the SAME question in multiple threads is self-defeating. People who try to answer don't know what's already been suggested, and end up wasting their time as well as the poster's time in providing the SAME answer and/or suggestions that were provided in the other thread.
Fourth, simple forum netiquette. In both threads the poster essentially hijacked someone else's thread. This is frowned upon in just about every forum that I've ever seen.

VISA resource name control: want to refresh list of COM ports programatically

When the app is running, and you first click this control, it takes 2-5 seconds to respond and populate the list for the first time.
Therefore, I want to auto populate the first time the application is loaded. Can I do this?
Solved!
Go to Solution.

Hi,
I'm joining in here since the thread addresses delay problems when using VISA resources.
I would like to share my experience when using VISA on real-time targets.
The hardware I use is a cRIO NI-9074 with two NI-9870 (4 x RS232 each) and one NI-9871 (4 x RS485). These modules are used in scan mode to avoid excessive port programming in FPGA.
My first problem was that the twelve COM ports of the NI-9870/9871 modules did not show up in the list of available VISA resources when placing a VISA resource control on the front panel or a VISA resource constant on the block diagram. However, the workaround using "VISA Find Resources" seemed to work fine. When starting the real-time program from the development machine, the list was populated and by indexing the list I was able to use the port.
BUT: When building an RT executable from this VI, deploying it to the RT target and setting it as startup, nothing happened. It took me some time to find out, that there has to be a significant delay (in my case about 10 s) before calling the VISA Find Resources function. Otherwise it will not give the correct output. By some reasons, the ports do not seem to be available when the RT startup application begins to run. I tried to play with the delay and found out that the resource list would be empty when calling the VISA Find Resources function almost immediately on startup, after a few seconds it would return the ports of the first NI-9870, after seven seconds the ports of two modules, and after about ten seconds all ports would be available.
I would appreciate if somebody could tell me what happens since it was quite a pain in the ass to solve this issue.
Best regards,
Karsten

FTDI virtual com port driver (VCP) and Labview 2009 - random connection loss

Hi,
I am using an FTDI chip to go from USB to serial communication (FTDI Driver: 2.06.00). It seems to work at first but then after some time the connection gets lost ("connection for the given session has been lost" or "I/O error"). This happens in MAX as well as the built executable of the program I am running. Latest VISA drivers are installed - 4.6. I have tried flushing the buffer before and after communication with both visa clear and visa buffer flush vis. The lost connection seems to happen randomly.
I have seen other threads about this issue but they never reach a resolution. One thing i notice is that there are two FTDI devices in this system and only one fails, however when I unplug the working device the one that fails is able to connect again.
To sum up here are the system specs:
Windows XP SP3
FTDI 2.06.00 and older 2.04.02 drivers both fail.
2 FTDI devices on the system - they do get assigned different COM ports
Labview 2009 run-time
VISA 4.6 run-time
Thanks for any help.

We use Targus ACH63US Super Mini USB 2.0 4-Port Hub. It doesn't require external power but if you have a high power device you will have to plug the Targus hub into two usb ports on your pc (one provides power and the other does power and data transfer). They provide the usb Y cable to do this.

CA-42 Com port issues - Commonfx.sys

Similar Messages

Maybe you are looking for