Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About MikahB

  • Rank
  1. Thanks for the thoughts. That subroutine is only called when I am writing a new row - to keep scan times as short as possible, only the "check if we are ready to write a new row" logic runs every scan. I'm sure the row number is correct because the DT has 4000 rows and I'm using the same MI54 row number to set the target for the Write Row function. I will check SI26 to see if anything is there.
  2. Have a real-time trend that my customer really wants to be able to compare to historic data. So, I came up with the following plan: - Real-Time Data is stored in a DataTable - call it DataTableCurrent - Allow User to Save DataTableCurrent contents into a History Data Table called HistOutput1 - When User enables History Trend, every time I write a row to DataTableCurrent, read the row from HistOutput1 with the same Row Number - Enable Trend Curve for destination Int from HistOutput1 And, viola - you get current data overlaying historic data of your choice. Trouble is, every time
  3. Hi Russ. Unfortunately, I do not believe there is a solution besides resetting the power, the mechanical eject requirement is part of the SD slot spec. If Unitronics could magically add a "Reset SD Status" bit, that would do it, but short of that I have no other solution.
  4. That's a bold move, Joe - I think that's out of my comfort zone. Thanks for the response, though - new battery + time set should have us all squared away!!
  5. Confirmed, battery is dead. Since I am offsite and there is no remote access (other than me emailing new versions of the program for them to install), can I directly manipulate SI 33-38 to allow the user to reset the time? Probably going to try it before this even gets approved, but at least I tried to ask permission first!
  6. Thanks for the information. I will add an indicator for SB8 and send him a new screen. That sounds like the right type of issue, will post back with an update.
  7. Just got a call from my customer, seems the date/time on the V1210 has reset itself. Program is all intact, but the date is now wrong. I am positive it was correct when I left last week. What keeps the date/time accurate in the machine? I'm going to send him a program revision to let him edit date/time, but seems like something we should only need to set once. This machine is used intermittently and when they leave it, they just turn the power off - is there something I need to have them do first?
  8. Russ - I had a similar issue and solved it using a Micro-SD to SD-Card extension cable (this one, in fact: http://www.amazon.com/Manufacture-Sdhc-micro-Reader-Extension-Cable/dp/B0085GGO92/ref=sr_1_3?ie=UTF8&qid=1429124566&sr=8-3&keywords=sd+cable+extension). I then mounted the plastic housing on the end o the cable to the outside of the enclosure and now you can get to the SD card without any trouble. There is one catch (of course). The PLC will not see the eject notification when you remove the SD card, so it goes along thinking (and indicating) there is an SD card prese
  9. Yeah, for this application the users run the machine which generates test data, then they need to take that data with them at the end of the session/day to fiddle with in Excel. So, having the SD card accessible was key, but you are correct that the extension cable problem has nothing to do with Unitronics software/hardware, it's related (if I understand correctly) to the standard spec on the card readers. Apparently they want a mechanical ejection to trigger an eject event. So, I instructed the users to simply restart the PLC if they need to eject and re-insert, and all seems okay now.
  10. Okay, think I found the culprit, it's the extension cable. Don't know exactly why, but if I pull the extension out of the SD slot on the panel, it registers the eject and things work again. I may try another extension as getting data out is critical, there is no network available, and it's not reasonable to expect the users to dismount the panel to access the SD card.
  11. Thanks, that's exactly my setup. It basically ruins SD functionality once it sticks "on," also. Re-inserting does not make the card readable, etc. I have tried re-formatting the (brand new) SD cards in Windows first, then with the SD Card Suite, no change. Not really sure what to try next.
  12. I was expecting SB 217 to Set when an SD card is inserted and to Reset if/when it is removed. What I'm seeing, however, is that when I remove the SD card the SB does not Reset. Is this by design or do I need to somehow initiate another "check" to see that the SD card is there?
  13. We ended up using an estimate by applying a fastener with a known torque and referencing existing torque/tension data - so that should be close. Only issue I have now is that the output from the load cells is oscillating strangely - both at zero and under load, I'm getting a very smooth, consistent sinusoidal-looking oscillation of about 0.1% of FSO.
  14. Wow, not sure why I had it in my head that it was 10V excitation - thanks for setting me straight. Regardless, my question remains the same. While I appreciate your concern, there is no safety issue related to the accuracy of force measurement on this machine. The load plate is 4" square and sits vertically, so as I said previously simply piling some known weight on it is not really feasible (or, indeed, safe). The load I was clamping yesterday was something like 20,000 pounds (very roughly). At that load, I was seeing Raw values of around 3150 which doesn't make sense to me even at
  15. Machine has 4 load cells (30klb each, 2mV/V) into a Summing Box, then the single output from the summing box going into LC2 on an I/O LC3. The Load Cells are measuring clamping force of a bolted joint and, as such, there is no real way to put a reasonable known weight onto the LC's and hit "Calibrate." Eventually we'll have a calibrator come out with a through-hole Load Cell to dial it in, but we need to get it in the ballpark to get started. In this application, relative values are more critical than accuracy so if we're off 5% no big deal. I used some simple math to determine that
  • Create New...