Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Joel Moore

Pages: [1] 2 3 ... 9
1
General Discussions / Double debounce design
« on: September 04, 2019, 10:55:49 AM »
I'm using an optical sensor to detect a gizmo on a part elevator.  Depending on the mode of operation (e.g. loading or unloading) the PLC will either be looking for the sensor to turn off or on to decide when to stop the elevator.  The gizmo is a little floppy so it can cause the optical sensor to oscillate between states at the edge of detection.  So clearly a de-bounce circuit is required.  One that de-bounces both transitions.

The attached image is what I'm using and it works but I'm always interested in finding more elegant/efficient ways to do things.  Have I made this more complicated than necessary or is this about the best that can be done?

Edit: By the way, the 2 second setting for the timer is just to make it easier to watch the behavior.  The actual timer is 100ms

2
Technical support / Re:PLC hanging
« on: January 09, 2019, 11:24:14 AM »
That's exactly what I just implemented.  Let's hope that puts it to bed.

3
Technical support / Re:PLC hanging
« on: January 09, 2019, 08:30:47 AM »
Thanks, support and Gary.

I've added a custom function that reboots the PLC when an unhandled interrupt is thrown.  Hopefully that'll take care of the unresponsive PLC issue.

However I did find that I was still having issues with the stepper motors "running away" despite the input I'm using as a "Run"signal being off.  After further investigation I think this input can be very intermittent or bouncy at certain points which probably resulted in quick successive and intermingled calls to STEPMOVE and STEPSTOP.  Maybe that's what was causing the interrupts.

So now I'm using the "Run" input to latch a relay which is what initiates the STEPMOVE and the relay doesn't get cleared until STEPSTOP is called.  I'll probably add some additional debouncing elements to further filter out unstable inputs.

4
Technical support / Re:PLC hanging
« on: January 08, 2019, 08:59:28 AM »
I haven't heard from TriPLC yet.  I was going to give them a chance to start their morning in CA before I contacted support directly.

Thanks for the tip about F8.  I'll need to trigger the error again before I can check if it can tell me anything useful since I stripped out some unused code since posting my message and I think the original address (006E) probably isn't valid anymore.
 
I did wonder though if FN #5 refers to FN #5 as seen in the code editor (which starts at 1) or is it the function index in the actual source file (which is 0 based).  Maybe the F8 key will clarify that point for me.

5
Technical support / PLC hanging
« on: January 07, 2019, 10:49:09 AM »
I'm using an FMD88-10 in a very basic application as a 2-axis stepper pulse generator.  We have some manual buttons, limit switches, and beam sensors all working together in a physical relay network to provide the PLC with "RUN" and "DIRECTION" inputs for each axis.  It's a very simple program, basically just STEPMOVE and STEPSTOP in response to these inputs.

A few times now the system has stopped working and upon connecting to the PLC I am presented with dialog box that says:

"Run-Time Error in Fn #5.
 Error: DM32[] index out-of-range".

In the ViewVariable dialog I can see the following message being printed to the virtual LCD display:

"Undef. Interrupt
CF #0005:006E"

Other info:
- Custom function 5 is simply the command "STEPSTOP 1".
- I don't have any interrupts defined.
- I don't use or refer to DM[32] anywhere in my program
- The PLC's firmware is version r76A

Thanks for any advice you can offer.

Edit: Corrected typo in error dialog message

6
Technical support / Re:STEPMOVEABS not always setting Move Complete relay
« on: August 17, 2017, 08:07:24 AM »
No, it's not used to trigger another move.  It is only clearing a couple of relays.  It's also used as part of an axis homing sequence but that also requires a particular state of the homing sequence to be active which would also result in the axis position being zeroed which isn't happening.

I'm not writing to the bank of relays that includes the move complete, only reading (RR05).  I write to a different bank (WR04).  I do write to a variety of relays as single bits but never the "move complete" one used with STEPMOVEABS.

One of the relays I write to is the one used to trigger the move in the first place however according to the captured data that only gets written to once when the move is initiated.  Between the points when the move is initiated and when I manually intervene the following conversation repeats continuously:

[Send] @01WR040040*      Write output state (use relays as a buffer between PC and PLC outputs)
[Resp] @01WR44*
[Send] @01RR0544*      Read status relays (this includes the move done flag R47)
[Resp] @01RR0948*                
[Send] @01Wb041AFF00*   Reset watchdog timer
[Resp] @01Wb74*
[Send] @01RVIX54*         Read axis position
[Resp] @01RVIFFFFE4437A*  
[Send] @01RI005A*         Read inputs
[Resp] @01RI0C29*

I think I'm going to write a little program to parse the captured data to look for anything unexpected.  It's a bit much (8 million lines or so) to peruse manually.  I'll probably eventually wind up implementing the secondary check as suggested above.

7
Technical support / Re:STEPMOVEABS not always setting Move Complete relay
« on: August 11, 2017, 12:15:07 PM »
Thanks for the thorough reply.  That's interesting about the counter issue.

I was actually considering using the absolute position as a backup means to check for completed moves since we're already pulling that information onto the PC as part of the regular update loop.  However this is all old code that I'd rather not have to poke too much at the moment lest everything falls to pieces so I was hoping to find out if there was a known PLC firmware issue that could be solved by upgrading.

This issues is actually something I only discovered on my own while trying to figure out a different problem we were having with one machine in particular.  I haven't heard any complaints from the field regarding this so maybe it's rare enough to be inconsequential.  

8
Technical support / STEPMOVEABS not always setting Move Complete relay
« on: August 11, 2017, 08:14:59 AM »
I think I've narrowed down the cause of a frustrating issue we've been having with our machine where a motorized axis would complete a move yet our PC-based control software would never detect that the move was complete.  It seems that on occasion STEPMOVEABS will successfully finish a move but the move complete relay never gets set (which is what our PC-based control software is monitoring).  By the way, this isn't related to the issue described here since we are definitely moving.

I narrowed it down to the PLC by capturing the serial communications between the PLC and the PC.  One of the commands in the PC software's update loop is to read a bank of relays (host command RR) which contains the move complete relay and the response clearly shows that the relay is not changing state.

My communications log captured 1255 sent commands that result in STEPMOVEABS, the last one of which failed to set the move complete relay.  That's many more moves/shift than a machine would typically make in a production environment but it's still concerning since I think it's reasonable to expect it to never happen.

Could the fact I'm reading the state of that relay many times a second via the RR command sent via RS232 be interfering with the PLC's ability to set it once a STEPMOVEABS is complete?  That sort of conflict would certainly explain why it seems so random.

BTW, we are using FMD88-10 PLCs.  If there's any other info that might be useful let me know.

9
Technical support / Re:How do I set a relay permanently using a custom function?
« on: February 01, 2010, 02:32:06 PM »
Two possibilities come to mind:

1) You're not referencing the correct relay with your SetBit call.  But this should be obvious if you monitor the PLC and see which relay is turning on.  I prefer to use SETIO and CLRIO instead since it's much clearer.

2) You're resetting the relay somewhere else in the ladder.  Nothing gets committed until the scan of the ladder is complete.  So if on rung #5 you run your custom function but on rung #10 another custom function (or traditional ladder rung) is clearing that relay then the relay will never get set.  

10
Technical support / Re:Interfacing with TTL logic
« on: January 18, 2010, 12:06:26 PM »
You're right.  It could very well be CMOS.  I'm just going by what the customer said.  And yes, it's an output that I'm trying to interface with the PLC's input and it's low speed.

I'll check out the 2003A chip.

11
Technical support / Interfacing with TTL logic
« on: January 18, 2010, 10:26:40 AM »
I was hoping someone here could help me figure out what I need for a circuit to connect a TriPLC to TTL I/O.  Specifically, the PLC's inputs.  I understand we need transistors but I was hoping for something a little more detailed.

I see the T100 Manual has a circuit on page 1-4 detailing something similar for CMOS.  Is this all we need?  I was under the impression that CMOS and TTL are not compatible so I was hesitant to implement what is shown there.

Ideally there would be a DIN-rail  mountable module I could use but either these aren't common for some reason or else I'm searching on the wrong terms.  The few I've found tend to be very expensive -- more expensive than is justified by a few transistors.

12
General Discussions / Generic ladder logic question
« on: January 08, 2010, 10:11:58 AM »
I'm looking for some advice on how to accomplish the following in ladder logic:

I have 3 inputs that are being used to command the PLC to move to 1 of 8 predefined positions.  I'm trying to figure out a robust way to respond to those inputs.  Ideally I want to make sure that whatever external system is controlling the inputs has plenty of time to make its changes before I start to move.  For example if the inputs are currently "0,0,0" and the external system is in the process of changing to "0,1,1" I don't want to initiate a move while the inputs are in the intermediate state of "0,0,1".

Currently I just have a 1s timer that checks the state of the inputs but that still leaves the possibility that I check the state while the inputs are in the middle of changing.

The best way, in my opinion, would be for a timer to start when the system sees an input change and the PLC won't initiate the move until the timer expires.  However there are a total of six events that could trigger the timer (3 inputs, either on or off).  I have no idea how to design this using ladder logic.

13
Technical support / Question about stepper motor behavior
« on: January 08, 2010, 09:45:49 AM »
This really isn't a problem I'm having but more an attempt to better understand how the TriPLC controls stepper motors.  Two questions really:

1) If you command an axis to move a distance that is less than twice the acceleration value what happens?  For example:

STEPSPEED 1, 2000, 500
STEPMOVE 1, 800, 1

2) What about if the commanded distance is less than the acceleration value:

STEPSPEED 1, 2000, 500
STEPMOVE 1, 100, 1

The reason I ask is because the sounds coming from my stepper don't often match my expectations.  It almost sounds as if it's accelerating a different rates depending on how far I tell it to go which doesn't seem right to me.  I would think the PLC would always try to maintain the same acceleration slope while lowering the max speed.

14
Opinions & Feedback / F-series...wow
« on: October 30, 2009, 02:54:17 PM »
I'm really impressed by the features included with the new F-series PLCS.  You guys really outdid yourselves.  Ethernet?  Two RS-485 ports?  Direct stepper driving?  Separate ground for I/O banks? (edit: Wow, and ZigBee support)

Unfortunately we no longer make the product that we used to buy TriPLCs for but we would have instantly replaced the MD888+ with the F2424.

We'll definitely keep this in mind for future projects.

15
Technical support / Re:Corrupted response from PLC
« on: December 04, 2008, 02:01:58 PM »
This is still a frequent problem.  I initially dealt with it by adding some retry code to our software but we still have problems.

There's no other code on PLC that uses the COM port so it's not stray data.  It happens on a number of controllers and PCs so it's not port damage.  Besides, it's always the same character location in the response which implies it's not random.

It's weird because we went for years without having any trouble and then suddenly this problem appeared.  One thing that's been pointed out is that the firmware version on the PLCs is newer than what we started with (r50 vs. r49 I think).  So naturally people are wondering if there could be a connection there.  A few questions:

- When was the PLC firmware updated to r50?

- Was anything changed that could affect the serial port communications (are there release notes available anywhere)?

- Is there any way to revert to an older rev of the firmware?

Pages: [1] 2 3 ... 9