C1086 Unsure of cause


Recommended Posts

I am trying to read data from a Relative Humidity/Temperature sensor and I keep getting error C1086 on line 53 " tempC = 175*tempx / 65535 - 45" when I am using this code on a Labjack U6 running numerous sequences for various processes. This error does not occur when I run it on an isolated Labjack with only sensor attached. I have checked all of my pin connections and there is nothing else running off of these pins, so there shouldn't be any conflicts. Can you point me in the right direction for troubleshooting this error, is there something wrong with my code or is there a conflict with this code and another sequence that I need to look into. I have attached the code below.


// Set the I2C address

AddRequest(ID, LJ_ioPUT_CONFIG, LJ_chI2C_ADDRESS_BYTE,136,0,0)


// SCL to CIO0

AddRequest(ID, LJ_ioPUT_CONFIG, LJ_chI2C_SCL_PIN_NUM,16,0,0)


// SDA to CIO2

AddRequest(ID, LJ_ioPUT_CONFIG, LJ_chI2C_SDA_PIN_NUM,18,0,0)


// Default (0) I2C options

AddRequest(ID, LJ_ioPUT_CONFIG, LJ_chI2C_OPTIONS,0,0,0)


//MISO is FIO3 conflict and not used? So commented out

//AddRequest(ID, LJ_ioPUT_CONFIG, LJ_chSPI_MISO_PIN_NUM,3,0,0)


//CLK is CIO0

AddRequest(ID, LJ_ioPUT_CONFIG, LJ_chSPI_CLK_PIN_NUM,16,0,0)


//CS is CIO2

AddRequest(ID, LJ_ioPUT_CONFIG, LJ_chSPI_CS_PIN_NUM,18,0,0)


//Execute the requests on a single LabJack.





This part above is done in a separate sequence but I included it as I think it may be related to the issue



// initialize the variables

private numWriteBytes=2

private writeArray

writeArray[0] = 36

writeArray[1] = 0

private dataArray

private numreadBytes = 6

private tempx

private tempC

private rh



   //Transfer the data (single shot acquisition command)

   ePut(ID, LJ_ioI2C_COMMUNICATION, LJ_chI2C_WRITE, numWriteBytes, @writeArray)



   // Wait 20ms for the acquisition time




   dataArray[0] = 0

   dataArray[1] = 0

   dataArray[2] = 0

   dataArray[3] = 0

   dataArray[4] = 0

   dataArray[5] = 0


   // Read the returned data

   eGet(ID, LJ_ioI2C_COMMUNICATION, LJ_chI2C_READ, numReadBytes, @dataArray)



   // Convert the raw bytes to actual readings

   tempx = dataArray[0]*256 + dataArray[1]

   tempC = 175*tempx / 65535 - 45

   rh = dataArray[3]*256 + dataArray[4]

   rh = 100*rh / 65535

   // print the read to the command / alert window.  Of course you'll probably do something a bit more exciting with the data



   ?Format("temperature=%0.4fC\nrh=%0.4f\n", tempC, rh)



Link to comment
Share on other sites

From a pure scripting point of view, the code looks ok.  TempX is declared private, and initialized.  I would either break, or add a ? line before the tempx = line to see what dataArray contains, so perhaps:

? dataArray

right after the errorhandler(ID) line.

Link to comment
Share on other sites

It still returns the error and does not print out ? dataArray, or ? tempx that I added after tempx = dataArray[0]*256 + dataArray[1]

The error also persists after commenting out the while loop to attempt to run it a singular time. 

Link to comment
Share on other sites

The ? was never going to fix the error.  I am assuming you did ? dataArray before the tempx= line?  If it is printing nothing, I would put another ? dataarray before the call to the LabJack, and maybe change the second one to isEmpty(dataarray), so:

? dataArray
eGet(ID, LJ_ioI2C_COMMUNICATION, LJ_chI2C_READ, numReadBytes, @dataArray)
? isEmpty(dataArray)

You'll probably get:




Link to comment
Share on other sites

I did put the dataArray before the tempx= line, but it still doesn't seem to print out anything. The IsEmpty(dataArray) does print 1, so dataArray is empty. Does this mean there is an error with the connection of the sensor to the labjack, or a conflict in the transfer of data?

Link to comment
Share on other sites

I think that the error is likely due to some DAQFactory configuration. I ran the section of code you provided without any valid I2C connection and I do not see any errors. I can force the error if I comment out the array declaration:

//private dataArray

 I suspect the issue is something related to the variable declaration or maybe scope.

The behavior we expect without a valid I2C connection is to read a logic high since the I2C bus should have pullup resistors installed. That should return an array of {255,255,255,255,255}. Reading zeros would indicate that the sensor is holding the line low, but as discussed above I do not think this is the issue.

Link to comment
Share on other sites

Did you say that it wouldn't print dataArray even before this line:   eGet(ID, LJ_ioI2C_COMMUNICATION, LJ_chI2C_READ, numReadBytes, @dataArray).  I.e. you have:

? dataArray
eGet(ID, LJ_ioI2C_COMMUNICATION, LJ_chI2C_READ, numReadBytes, @dataArray)

and you don't see {0,0,0,0,0,0}?

I would just rename that variable to something else, like MyDataArray.  Also use fill() to initialize it:

private MyDataArray
MyDataArray = fill(0,6)
? myDataArray
eGet(ID, LJ_ioI2C_COMMUNICATION, LJ_chI2C_READ, numReadBytes, @myDataArray)
? myDataArray


Link to comment
Share on other sites

I had renamed the variable and added in all of the recommendations and I am no longer getting the error, so there must have been some typo I had accidentally added.

I am confused on why it is setting the array to {255,255,255,255,255,255} because these should be different numbers based upon the data being read from the sensor. I have it connected again to the isolated setup and the dataArray changes values, but on the main setup the values remain a constant 255. Would this be an issue of sensor connection to the labjack? I am using the same pins to run each process and there is no other conflicts, but I am running the isolated setup with a CB37 terminal board as opposed to a ribbon cable on the main setup. 

Link to comment
Share on other sites

The 255 values means that the LabJack is not detecting any change in the data line. That could be due to a software I2C configuration issue or hardware issue. If your software setup works with one hardware setup but not the other, it should indicate that there is some hardware related issue. However, if you are running your tests on separate computers I would not completely rule out software differences/issues. I would suggest probing out the data and clock lines with an oscilloscope or logic analyzer to see what is going on with the bus.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.