Jump to content

MikahB

Members
  • Posts

    18
  • Joined

  • Last visited

Everything posted by MikahB

  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 I run the Read Row From Data Table FB, I get zero as a result. Here is what I have checked and know for sure: 1) HistOutput1 does indeed have the data I want - I can export it to an SD and see exactly what I expect 2) The RowNumber I am trying to read is a valid number - I am using the same variable to write the current row in DataTableCurrent as I am to read the row from history, the two FB's are in the same rung and the variable cannot change 3) There are no data type mismatches - Everything is ML 4) The rung containing the Read Data Table Row is executing as the next FB in line is properly writing data to DataTableCurrent I'm kind of out of ideas as to what I need to check. From everything I can see, no matter what I do to call this FB I get a zero back. Screenshot attached of what I have now. The disabled rung below divides to give me a trend-able number, thought that was the problem but ML403 is always zero.
  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 present when there is not. Only way to get it to reset is to restart the PLC. For my application it's not a big deal - hopefully it's okay in yours also.
  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. Maybe adding a FB to trigger this SD card eject event could be a future addition. The extension cables really do make it nice to get an SD card accessible outside the cabinet. In this particular case, not having the SD card capability would have meant I could not use the V1210.
  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 5V excitation. I was also seeing Raw values of around -200 with no load which also doesn't make sense to me (it is not possible for these button-type load cells to be under tension). I guess I will just experiment with it today. Some help would be much appreciated, though.
  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 it should take 111,000 or so pounds to reach 80mV/V output which is the top of the scale. Question is, if I use Edit Calibration Point and fake in a Zero and a Full-Scale Output point, will that get me reasonably close to accurate? I thought it seemed workable - theoretically 0.8mV (80mV/V * 10V Excitation) should end up at a Raw value of 8,388,607. But, when I was looking at data the Raw values were about 1/8th of the pounds I was expecting to see, so that kind of shot my theory up a bit. Anyway, hopefully this makes some sense and someone can shed some light!
  16. Thank you, Simon! Exactly what I was hoping to hear - especially since our proposal was accepted including this equipment yesterday. A new Unitronics customer is born!
  17. I'm perfectly happy to be informed if this is an incomplete (or incompetent) question - any thoughts?
  18. I have a project for which I believe a V1210 would be a perfect fit. The machine is simple - one large motor driven by a "smart" driver which performs all PID control, only needs Start/Stop/Enable input from the V1210 (possibly down the road add target speed output from V1210 to Motor Driver). The machine runs intermittently performing tests, each test runs for roughly 3 minutes then stops. The tricky bit I'm running in to (as I look for controller options) is that I need to read and log two analog inputs at something like 100Hz. In a perfect world, I'd even like to be able to display one of these analog inputs as the Y value on a line graph with a cycle-count as the X value (display obviously does not have to be at 100Hz). Looks like there is more than enough time as far as analog input scan time and conversion time, but I'm not sure about being able to write/log values at this rate. Also not sure about being able to integrate that logged information into a real-time graph as mentioned above. Does this seems like a reasonably good fit?
×
×
  • Create New...