Jump to content

Flex727

MVP 2023
  • Posts

    3,325
  • Joined

  • Last visited

  • Days Won

    241

Posts posted by Flex727

  1. Now you know why I use incrementing an ML with SB 13.

    Another option is to store the Preset and Current TA values in an ML, subtract one from the other and store that value in another timer to save in your Data Table if you simply must have the timer formatting. This would only require a few ladder rungs to accomplish.

    This is something I rarely need in my programming so I haven't spent any time exploring alternatives. Maybe someone can offer another suggestion.

  2. No, the TA timer will not lose its value when the PLC is power cycled. However, make sure you understand how the TA timer works. It counts DOWN, not up. It also must be RESET by ladder when to reaches zero to allow it to begin to count again.

    You can display the Data Table on the screen using the "Data Tables - Copy Row to vector" and then displaying the vector of MIs, breaking them into the appropriate pieces using the HMI variable ASCII String. Sadly, there is no function to just throw the whole Data Table onto the screen - you just have to do row-by-row. You can, however, display as many rows simultaneously as you have room for on the screen using the appropriate logic.

  3. You shouldn't lose any data during a power cycle. I normally have a column for date (String, 10) and time (String, 12) using RTC To ASCII #7 for date and RTC To ASCII #9 for the time. Then at each data store point I Copy Rows from Row #0 to Row #1, number rows = Data Table size minus 1. After the copy,  do a Write Row into Row #0 with the Date, Time, and the Timer value into the 3 columns.

  4. Are you using VisiLogic or UniLogic? If VisiLogic, remember that timers can only run for 23 hours, 59 minutes, & 59 seconds. You can either set up some logic to counts days and add that to your data table, or do what I like to do. I like to use SB 13 to Increment an ML. From there you can convert to hours + tenths of an hour, formatted as HHHH.H easily by dividing by 360.

    The data can easily be stored to a Data Table at whatever interval you desire. You can do this daily at midnight by turning on a bit when SI 35 = zero. Use a positive transition of that bit to store to a data table row.

  5. Am I the only one who would love to see VisiLogic download a starting value for a numeric operand without the Power-Up checkbox being checked? In other words, it would place a value in the operand that could be overwritten by ladder, but not by start up. This behavior would be exactly like what happens with Timer Presets.

  6. 26 minutes ago, Ramiro said:

    I connected an ampherimeter to measure the real current and it measure 4 mA (in online test I read 203 count)

    The reading of 203 would be a measurement of 3.995mA. Is 0.005mA really a concern to you?

    27 minutes ago, Ramiro said:

    I read at 4 mA 816 count, it is not correct measure (819)

    This reading is only off by .004mA.

    This all sounds really accurate to me. What is the issue you're having?

  7. I've had similar problems during program development. After re-downloading the project to the PLC several hundred times, the image memory can get corrupted somehow. It's easily fixed (as Simon says), by downloading a BLANK project then re-downloading your program. This only occurs during program development when the project gets downloaded too many times - it no longer occurs once the program is in service and is no longer being downloaded from VisiLogic.

  8. Do MB 21 and MB 30 stay on? If so, you may be trying to communicate too fast. Use something like this, but replace MB 21 & MB 30 with what you REALLY want to initiate the comm (or just delete them entirely if you want to continuously run the data transfer). You can change TD 20 preset to whatever works for you, but 100ms should be plenty slow to avoid dropped packets.

    image.png.2369c093d7d0665244e1ecd9165c2e7f.png

  9. 17 hours ago, LoganS said:

    For the modbus, are u suggesting that instead of using the timer based one shot, I replace with something that will just continually set a bit to request the modbus read and write, having the end of the FB reset that bit?

    No, I am suggesting that whatever you use to trigger the MODBUS read or write, whether a timer, or an HMI pushbutton, or anything else, have that trigger set a bit and then use a direct contact of that bit to trigger the MODBUS read with a reset of the bit at the end of the rung, like this:

    image.png.76b537d8ce54537246dd9ed1c004e982.png

  10. Here is a list of issues that I noticed at a glance (the first 3 items are just about best programming practice - they won't prevent your code from working):

    Rung 1 - Use the Power up with the operand instead of SB 2.

    Rungs 7-10 - ALWAYS use a transition contact to load an HMI display (I recognize that your code would have the power flow on for only 1 PLC cycle, which is why it works). Also, don't add any code in the same ladder rung after an HMI call FB.

    Rung 11 - Just use SB 2 for all your comm initializations. I'm finding it surprising that your tap machine (or whatever the MODBUS slave is) takes that much longer than the PLC to boot up, but if so, then I suppose you have to do it the way you are. However, use SB 2 to initialize everything, then place your delay on the connect only. The PLC doesn't care, but it's better programming practice.

    Rungs 19-22 - You need to SET a bit for your read and write, then RESET the bit at the end of the MODBUS read & write (similar to what you correctly do for the connect & close functions) to allow for the busy bit to be on. This may be why you were seeing unpredictable results without the timers. 

  11. Just a quick glance and I see that you have your analog input as the output of a linearization FB in rung 10 of the linearization subroutine. That will not work. You have a lot math in rungs 8 & 9 that makes little sense to me. Until you get the motor running the way you want, simplify everything to a direct input of the RPM on the HMI screen with a readout of the RPM from the analog input visible on the screen.

    Also, be sure you are using 3277-16383 for that 4-20mA analog input, not 0-16383.

  12. 59 minutes ago, Dancho said:

    Is this the 'right' time to use real numbers, or just another way to handle those things?

    I've been doing this for many many years and can't remember the last time I needed floating point numbers in my program except for some crazy flowmeters that insisted on outputting their data via MODBUS as floating point. Insane, if you ask me. I guess if you have a situation where the number of significant figures in the decimal varies and is unknown at the time of programming then floating point is necessary. Other than that it's poor programming practice in my humble opinion.

  13. 6 minutes ago, Dancho said:

    1.  When is the 'right' time to use real numbers?

    Almost never. Multiply by 100 or 1000 (or whatever precision you need) in your linearization function block and then keep track of the location of the decimal point through any subsequent calculations. The HMI display function for integers has a handy virtual decimal point that you can use for display.

    11 minutes ago, Dancho said:

    3.  If I want to know both positive and negative values, should I use multiply by 100 or 1000 AND choose 32768/2 as the zero point?  As in, shift the values, so that below 16384 represents a negative volumetric flow?

    I spend most of my time with VisiLogic rather than UniLogic, but my recollection is that the 16-bit integer registers are signed (VisiLogic has both signed and unsigned 32-bit registers, and only signed 16-bit registers - I think UniLogic is the same). Just use negative numbers as you normally would. Just be careful about register overflow and divide by zero.

    15 minutes ago, Dancho said:

    For example, is there a clever/elegant way to calculate the volumetric flow from the 0th element to the 1st, 2nd, 3rd, so on...getting 9 values and averaging, sorting, etc. to get a less noisy signal?

    It seems I'm always dealing with converting flow rates to volume (most of the time) and volume measurements to flow rate (less often). Either many system designers don't understand that they need to use the proper sensor for the job at hand or they just go with whatever is cheaper at the moment (sometimes you need both flow and volume so conversion is necessary regardless). Converting between those two domains is very cumbersome and elegant solutions are rare.

    For converting flow to volume, you need to integrate. I just time slice the flow (usually in 100ms increments) and sum (there is some additional math involved to get the units correct). For the reverse, you just have to measure the volume as often as you can, calculate the time interval and filter as heavily as needed to get something approximately matching reality. If there's a better way, I sure would like to hear it.

×
×
  • Create New...

Important Information

This site uses cookies. By clicking I accept, you agree to their use.