Jump to content

Damian

UniStream & UniLogic Beta
  • Posts

    534
  • Joined

  • Last visited

  • Days Won

    13

Posts posted by Damian

  1. Hi emil

    Thanks for your reply.

    I have been through the pid help but I'm still struggling with how to connect the pid to an output and also how to use my linearised transmitter signal as an input

    Normally, to tie a PID output to a single physical digital output you will send it through a PWM block. You will want the cycle time to be long if you want to slow down the switching.

    Your proces value should go directly into the PID block.

  2. I learned my lesson a long time ago with Visilogic and windows settings. The entire first year I used it (under XP), there were many things on the screen that I wasn't seeing that I wasn't even aware that I wasn't seeing. I remember one day I was frustrated because I wanted to know where my pixel location was on the HMI screen and I complained that they needed to add this feature. I was then informed that in fact that feature was already there. Where?!? Well after some investigation and monkeying around it was found that the "Silver" theme I had chosen didn't jive well with Visilogic and literally caused many things not to display (including the little pixel location box). ARGHHHHHHHHHHHHHHHHHH!!

    That is another thing they need to be wary of on NG is try to make sure they program things in such a fashion that the windows setting and themes don't interfere with the experience.

  3. Hi Russ,

    Some comments, and only meant to be taken constructively.

    Never use Set and Reset coils on physical outputs. In fact I recommend avoiding them when possible in most other cases as well. Especially in the beggining when you are learning. It makes for very messy and fragile programs.

    You set an ouptut based on an equal comparator. This means that the value has to be EXACTLY equal to your compared value at the the time it scan this. Generally I would expect to see a <=, >=, or a LIM.

    Please describe in real world terms what you are trying to achieve so that we know you are taking the right approach.

    The way you have written this, even when the timer completes, if the comparator remains equal you will immediately set the Output again before the timer has a chance to reset.

    Timers can be reset using and --®-- of that timer number. I don't prefer this method myself, but it is an option.

    I will post you an example of a simple self resetting timer that used "sealed in" type logic, as opposed to "latch logic"

  4. Thank you, everyone.

    I am still reeling from the statement about "he just asked and we made it for him" Wow. That's nice.

    In my previous project I could never get more than one socket to work, so I was limited to the number of stations I could have.

    And since they all had to use the same socket, it slowed down the communication time as I was sending and receiving data from 30 other PLCs. I wanted to break it up and fewer PLCs on each socket.

    That was back in version 7 or 8 though. I am excited to see how the new version has been improved and I am looking forward to using the new com blocks.

    Thanks again.

    Cara left out all the whining, complaining , and groveling I did. I originally simply asked that R&D check into why the connection times were taking so long and see if it was just a matter of some time delays being set too conservatively. I was given the impression that it ended up being more time consuming than was originally anticipated. I never expected the development of new FBs.

    Even prior to that though, I never had any issues with having all sockets connected simultaneously. I originally developed my messaging routine back in version 7. Greater than 80% of my application involve ethernet. My problem was more so that once you had more than 4 nodes, 1 or more sockets had to be shared. Then my sampling rate on the shared socket would go from a blazing fast read & write cycle of 12.5ms to an abysmal 150ms per device on the shared socket. The fast Connect block allowed me to open, read, write, close, and then connect to the next device in less than 30ms per device. Still not blazing fast, but it did make certain applications more feasible that I would have otherwise has to use a high end controller for. I am curious as to why you had so much difficulty. I suspect you didn't have something quite right in the config.

×
×
  • Create New...