LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Fatal error: protocolsup.cpp

Hi Andicarol,

According to the Knowledge Base: Known Issues and Bug Fixes for LabVIEW 8.5 Real-Time Module, this issue (42TCTSSQ) should have been resolved. Could you please post a detailed description on how to reproduce the error so that the error can be validated? Thanks!
Ryan D.
District Sales Manager for Boston & Northern New England
National Instruments
0 Kudos
Message 11 of 34
(2,889 Views)

Hi evrybody!!!

I have the same problem... FATAL INTERNAL ERROR: "protocolsupp.cpp", line 3218

I have LV version 8.2.1

If I have understand, a the moment there isn't a solution! Right?

 

Enjoy your holiday!!!

0 Kudos
Message 12 of 34
(2,867 Views)

Hi Fabio,

Are you using the Real-Time Module with LabVIEW 8.2.1?  As Ryan mentioned, this was reported to R&D (# 42TCTSSQ) and was thought to have been resolved in the LabVIEW 8.5 Real-Time Module.  However, similar behavior has been seen in Real-Time 8.5 and was reported to R&D (# 4DCEIP68) for further investigation.  Unfortunately the only known solution is to remove the breakpoint causing the crash, but the issue is being investigated.  Sorry for the inconvenience. 

I hope you enjoy the holidays as well!

Jennifer R.
National Instruments
Applications Engineer
0 Kudos
Message 13 of 34
(2,834 Views)

Hi Jennifer,

I’m using the Real-Time Module with Labview 8.2.1. I put the breakpoint because I have to investigate for a problem in my VI. If I run it Labview quit and I haven’t information about errors.

Can you help me? Is there a log file that store errors?

Thank you very much for your help.

 

Merry Christmas

 

(excuse me for my bad english)

0 Kudos
Message 14 of 34
(2,827 Views)

Hi Fabio,

You can choose whether or not errors are investigated at startup under Tools >> Options >> Debugging.  With this option selected, when LabVIEW is restarted after a crash you will be asked if you would like to investigate the error.  Any error logs generated are stored as text files under My Documents\LabVIEW Data\lvfailurelog.  Feel free to post the log (as a separate thread if it's not related to this one) or contact National Instruments for support.  You may find other debugging tools such as Highlight Execution and the Probe tool useful as well. 

Jennifer R.
National Instruments
Applications Engineer
0 Kudos
Message 15 of 34
(2,802 Views)

Hi Jennifer,

I finished my holiday and I'm sad :-(... I have another question for you... I try to explain... I made a project for cRio and I made a VI for FPGA and another for RT. In the VI of the RT I use the TDMS block, but when I run it the cRio reboot and I loose the connection... I'm sure that the problem is the TDMS block because I haven't problem without it. I want to understand what is the problem. Can you help me?

 

thank you very much!!!

0 Kudos
Message 16 of 34
(2,768 Views)
Hi,

I don't know if this was obvious to everyone from the title of the .cpp but I noticed this problem when I insert breakpoints in VIs running on RT that have TCP/IP modules. I'm not sure if the Fieldpoint and RIO modules have TCPIP abilities but if you're running RT you *could* potentially use it.

As a general rule if you have left any TCP/IP modules with timeouts of infinity (or unwired) I found I would get this error more often. Recently, I wired all my timeouts and I havn't had this error as much.

I personally believe the error is TCPIP specific and may involve that fact that the debugger is (intentionally or not) using the TCP/IP buffering (either OS level or ethernet card level) when a breakpoint is hit and maybe overfilling this buffer or not updating enough state information (like a write pointer in the buffer).

If nothing else I hope my post might help someone searching for support for this issue if they've narrowed it down to TCP/IP but if no one else is using TCP and STILL getting this error I'd like to know.

-Alex W.-


Message Edited by AlexDubya on 01-07-2008 05:19 PM
Message 17 of 34
(2,736 Views)

Fabio,

Do you mean to say that having TDMS VIs on the block diagram of your RT VI causes your cRIO to reboot? If this is the case please post a simple VI that will do this. Also, what cRIO controller are you using?

Charlie M. CLD
0 Kudos
Message 18 of 34
(2,684 Views)
The functions on the TDM Streaming palette do not run on VxWorks. Of course, they are supposed to return a proper error message, so if they crash the target, that would be a bug. If you want to write TDMS files on VxWorks, for now you would need to use a set of VIs published here: http://zone.ni.com/devzone/cda/tut/p/id/6471.

Herbert
0 Kudos
Message 19 of 34
(2,654 Views)

Hi Charlie,

I use Labview 8.20 and my cRio controller is 9001 (i have to check). The answer to your question is Yes I do. If I use the TDMS I have the reboot ... As soon as possible I'll attach a simply VI

 

thank you very much

0 Kudos
Message 20 of 34
(2,596 Views)