Hello everyone, originally I was using a motor current sensor with a current transducer on my driver, which has been effective. Depending on user settings such as speed and step length, the sensor values follow a somewhat sinusoidal pattern. When effort is exerted, there is a noticeable drop in the current sensor value and trend line.
My approach involves scanning the device for 5 seconds to determine the minimum sensor value (minSV) as a reference point. If the sensor value drops below minSV when effort is applied, it indicates exertion. While this method is accurate, I find that every time I adjust settings such as speed, a "rescan" is necessary to reset the baseline on the sensor. Additionally, there is a slight current decay over time which can impact program consistency.
Considering the similarities between the current transducer and RPM output graphs in response to effort, I am exploring the idea of using RPM as an alternative to potentially reduce the need for rescan and parts, provided it is equally sensitive. I would appreciate any insights on this matter. It is worth noting that the only relevant sensors I have for this project are the encoder sensor for counting RPMs and the motor current sensor.
When it comes to achieving the desired results, feedback from the current appears to be crucial. Consider a scenario where someone puts in just enough effort to sustain the same pace. In such a case, there would be minimal current flow, yet the speed remains constant. Instead of labeling it as effort, it should be referred to as work for better clarity. The key is to distinguish between the work performed by the machine and that by the individual. As work is measured in joules and power is calculated by joules per unit of time (watts), the focus should be on measuring watts - with voltage assumed to be constant, the emphasis shifts to current.
How frequently should the sensor be read in order to accurately determine speed? To improve speed measurement accuracy, aim for more scans per revolution instead of waiting 5 seconds. Keep track of samples and identify each instance where a sample transitions from being greater than the previous one to being less than the previous one. This transition is known as a reversal, and the time between reversals should be measured. Each revolution consists of two reversals. For example, at 25 RPM, there are 2.4 seconds per revolution and 1.2 seconds between reversals. By sampling at 10 milliseconds, you can accurately capture the time of reversal and calculate speed effectively.
When analyzing data, it is crucial to consider its nature - whether it is smooth or noisy. In cases of noisy data, it is important to implement a deadband to prevent sampled fluctuations from being mistaken as significant reversals. This ensures accurate detection of peaks, troughs, and changes in direction.
To determine local maximum and minimum values in a time series, the dead band magnitude (∆) is crucial. This value represents the distance by which the RPM should drop below the most recent high (HI) to be considered a true local maximum, or rise above the most recent low (LO) to be deemed a local minimum. Every time theCode:AMPL = HI - LOstatement is executed, a new maximum or minimum is identified, resulting in a fresh amplitude value approximately every 1.2 seconds.
Given the ambiguous nature of the task at hand, I will propose a solution that initially comes to mind. One approach could involve implementing a blockhead solution using the formula: if the absolute difference between the current value and the previous value is less than the maximum allowable change per time interval, then update the values using a series of mathematical calculations. In case the condition is not met, simply increment each value by the difference between the current and previous values. This method can help minimize potential noise issues. Consider running this algorithm on a timer to ensure timely execution.
I am finding it challenging to follow the recommended approaches for data processing on a PLC for the first time. As a beginner in this area, I may need some time to fully grasp the concepts. I am utilizing Ladder in Automation Studio for this programming task. The machine requires various user settings such as step length and speed (speedSet). Additionally, there are other data metrics available including live speed (liveSpeed), live RPM (liveRpm), and motor current sensor value (liveCurrentSV). To determine the most reliable metric for the task at hand, I need to analyze and compare these noisy data sources. The liveSpeed fluctuates around the speedSet value due to the linkage system. The footplates move irrespective of user input, posing a challenge to differentiate between machine-generated and user-generated work.
To achieve the goal of distinguishing between machine work and user work, I aim to assess the sensitivity and reliability of each metric. I aim to identify instances of user input accurately, potentially using a light indicator as a simple solution. Currently, I am using the motor current sensor to detect user work. I assess the minimum current value every 5 seconds and compare it to live sensor values to detect user input. However, I am concerned about potential inaccuracies arising from slight current decay during a session, leading to the need for frequent rescans. I seek to optimize this process, minimize rescans, and reduce oversensitivity in the "work detector" algorithm.
I plan to incorporate images displaying the RPM and sensor value plots for reference. Thank you for your assistance.
When adjusting the HMI speed (setpoint?), a 5-second re-scan is triggered to establish a new minimum current value baseline. How can you ensure that the user remains idle during this brief interval?
drbitboy inquired about the potential issue of users not performing any work during a 5-second re-scan triggered by a change in HMI speed. This concern raises questions about the reliance on users to follow instructions while the device recalibrates. Some team members suggest instructing clinicians to guide patients through the calibration period, but ensuring user compliance may be challenging. To minimize confusion and misuse, reducing the frequency of rescans for HMI speed adjustments is essential. Challenges in accurately predicting the new sensor value post-speed change include motor start-up time, current decay, and other variables. Similar technologies incorporate calibration periods lasting around 30 seconds to establish reference points. This calibration process involves instructing users to warm up and allow the machine to calibrate accordingly.
In a forum thread, a user named afm mentioned having a 5-second scan. They asked two questions:
1. Is an adding machine being used as a PLC in this scenario?
2. What is the frequency of the sinusoidal signal when viewed with a 5-second scan interval?
AFM raised a valid concern about the trust placed in users to provide accurate measurements from an uncalibrated device. While some team members believe clinicians can guide patients to "go along for the ride" and start working when indicated, relying solely on this method may pose challenges. Obtaining reliable data from such a device, without the ability to calibrate it, will undoubtedly be a daunting task. Best of luck with this endeavor.
MaxK asked two questions: 1. Are you utilizing an adding machine (possibly an abacus) as a PLC? 2. What is the frequency of the sinusoid when observed during a 5-second scan?
I am currently using a B&R X20 PLC. The 5-second scan interval was chosen arbitrarily during testing, as 3 seconds did not provide an accurate minimum and 10 seconds was excessive. The frequency of the sinusoid depends on the user's configured speed and step length, but it will match the time required to complete one step.
Is there potential in this approach? It appears that the current sensor, speed, and rpm have not been entirely reliable due to varying torque requirements within the revolution, resulting in a range of values instead of a clear reference point. However, the step period should remain consistent and predictable based on the HMI settings. Even if the speed/rpm fluctuates within a step, the period per step should remain constant to maintain an average rpm.
Based on the user's settings, I should be able to establish the step period as my reference point. If the user performs work, the speed/rpm may briefly increase, leading to a faster completion of the step (if StepTimeLive < StepTimeSet -> UserWork). This approach could potentially streamline the process and eliminate the need for scan times. What are your thoughts on this strategy? I will begin testing it soon.
Let's take a step back for a moment. Is it correct to say that there is an HMI speed control setting known as a speed setpoint? The units of this speed setpoint are measured in footplates' RPM, or strides per minute, equivalent to half of steps per minute (a stride consists of a left-step and right-step pair). The motor control system works to maintain the footplates' RPM at the setpoint by adjusting the current to the motor. Even when the footplates are not in use, the system's resistance to movement fluctuates throughout the cycle. This resistance follows a sinusoidal pattern corresponding to the footplates' step cycle, which is twice the stride frequency. The sinusoidal resistance leads to a similar variation in the system's instantaneous speed (possibly measured by liveRPM). In the absence of user's feet on the footplates, the current provided by the motor control will adjust cyclically to counteract the speed variations caused by changes in resistance. These fluctuations in current mirror the sinusoidal changes in resistance. It's important to note that this explanation may not directly address the topic of the discussion, but it aims to deepen our understanding of the system.
MaxK inquired about the use of an adding machine or abacus as a PLC, as well as the period of a sinusoid with a 5-second scan. Drbitboy pointed out the difficulty of obtaining valid measurements from an uncalibrated device. The discussion delved into the HMI speed control setting and the system's resistance to movement, which results in sinusoidal variations in speed and current. While not directly answering the initial questions, the conversation provides insight into the system's design. Apologies for any confusion, and clarifications have been made regarding the system's operation and terminology.
The current RPM/speed in the system exhibits sinusoidal behavior, as previously discussed. I am exploring the use of the period as an indicator of work completed. When work is being done, there is a noticeable decrease in the period (time taken for one revolution or stride). The theoretical period, based on the setpoint speed/RPM, serves as a reference value and remains constant unless the speed is adjusted.
To determine the "livePeriod" in the system design, which involves moving footplates with an encoder wheel containing 8 slots (8 pulses = 1 revolution = 2 steps), one approach is to time how long it takes for a counter to reach 8 pulses, signifying one revolution. This timing process yields the livePeriod, but it provides data only once per revolution. For a more responsive program, obtaining livePeriod data at least once per step is ideal.
To calculate the liveRPM, the duration between pulses is multiplied by 8 (pulsePeriod) to obtain the period of the revolution, which is then used to calculate the RPM. Due to system resistance, the pulsePeriod may vary significantly between readings within a single revolution, leading to sinusoidal changes in RPM. However, the sum of all 8 pulsePeriod values should equal the theoreticalPeriod for each revolution, unless work is performed.
An attempt to improve responsiveness involves using the pulse period multiplied by 8 pulses to achieve real-time results. However, at higher speeds, this method may result in inaccuracies, such as spikes in "UserWorkDetected" even when no work is being done due to varying pulsePeriods.
For a more stable livePeriod variable, consider storing the latest 8 pulsePeriod values and calculating the sum as livePeriod. This approach ensures frequent updates while minimizing sensitivity to device resistance. Any suggestions on optimizing this process would be appreciated. Thank you!
To accurately measure the rotation of each pulse from the encoder, consider using a crank angle sensor to determine its contribution, especially since each pulse does not exactly equal one eighth of a revolution. If a crank angle sensor is not available, creating a table of degree values for each pulse can also assist in aligning the pulse count. Additionally, if the encoder wheel's lobes have the same on and off times, you can increase resolution by counting both the leading and trailing edges of the pulses.
Regrettably, I am currently limited by the hardware I have. One challenge I am facing is the lack of an incremental encoder sensor, which means the device can start or stop in any position, making it difficult to track the location of the footplates along its path. If I had this sensor, I could identify areas of higher or lower resistance and create a degree value table. However, I did notice that my encoder wheel has equal on/off lobes, which could potentially provide more resolution. I am intrigued by the idea of utilizing this feature. Do you have any suggestions on how I could optimize the livePeriod value for this application?
Is it possible to incorporate a reference sensor that enables you to precisely determine your position within one rotation of the encoder wheel? This feature will enhance the accuracy of tracking your location during the cycle.
According to afm, a more efficient method is to utilize a counter to time the occurrence of each revolution by counting pulses until reaching 8, indicating one complete revolution. This approach, known as livePeriod, provides feedback only once per revolution. To enhance responsiveness, the program should update at least once per step. By implementing an eight- or sixteen-element FIFO array to store transition times, the programmable logic controller (PLC) can continuously calculate the time between the past 8 or 16 transitions, updating the value with each transition. This results in an updated value every quarter or eighth of a second, ensuring accuracy despite any discrepancies in blocker lengths.
drbitboy suggested the implementation of an eight- or sixteen- element FIFO array in order to calculate the time duration of past transitions for a PLC system. By updating the value at each transition, a one-cycle period can be updated every quarter or eighth of a second. The comparison of transitions occurring one complete cycle apart ensures accurate calculations even with irregularities in blocker lengths. Utilizing a pulse encoder wheel sensor trigger, the pulsePeriod can be captured into the FIFO with 8 or 16 elements. The livePeriod will then be calculated as the sum of all FIFO elements, allowing for comparison against the reference theoreticalPeriod multiple times per revolution. While FIFOs may be unfamiliar in Automation Studio ladder function blocks, an equivalent FB may exist. Seeking input on FIFO usage in AS and approaches to this task is essential for successful execution, especially when working within hardware limitations. Future plans may include incorporating a reference sensor/incremental encoder, but for now, all efforts are focused on exploring available options.
In Automation Studio, FIFOs are not commonly referred to as such in ladder function blocks. If you are looking to implement a FIFO in Automation Studio, there are alternative function blocks that serve the same purpose. Have you had any experience with using FIFOs in Automation Studio? How should one go about approaching this implementation?
There are at least two commonly used ways to implement a FIFO. Before diving into the implementations, let's define a FIFO: a FIFO is an array that stores a series of measurements from events. Each element in the array has a value (measurement) and a position (index) within the array, making it unique and useful for sequencing events.
One implementation involves a linear array that maintains a constant relationship between event ordinal and array index. The arrival of a new event triggers two operations: unload and load. The unload operation removes the oldest event value from the array, shifts the remaining values down, and decreases the array length. The load operation adds a new event's value to the array and increments the array length.
Another implementation involves a circular array where each event's value remains at its initial index, allowing for a variable relationship between event ordinal and array index. The arrival of a new event triggers operations to remove the oldest event value, write the newest event value, and update the index accordingly.
It's important to note that vendor-supplied FIFO instructions may include built-in mechanisms to trigger shifts only when necessary, preventing unnecessary operations on subsequent scan cycles. While both implementations provide the oldest and newest event values, the circular array method offers a different approach and may require manual implementation if not supported by the vendor.
Consider implementing one of these FIFO methods in Automation Studio to effectively manage event transitions and calculate time differences for your application.
Drbitboy explained two methods for implementing a FIFO, which is an array used to store measurements from events. Each element in the array has a value and position, making it unique and practical for tracking event sequences. One common implementation is a linear array that maintains a constant relationship between event order and array index. Another method is a circular array where each event's value remains at its original index.
For a specific application involving a linear FIFO, a one-shot trigger is used to capture pulse periods from a sensor. When the array is full, the load and unload commands remove the oldest element, shift the array values, and add the newest pulse period. Continuous summing of the array elements provides a live period for comparison.
However, the challenge lies in creating arrays in Automation Studio, as familiar FIFO commands are missing. This obstacle complicates the implementation of the desired logic for tracking pulse periods accurately.
Regrettably, there is a lack of B&R experts on the site. When using "B&R" as a search keyword in the forum, you will notice several threads with no responses. You can consider reaching out to capinwinky and requesting their input on this topic. They have a history of providing valuable B&R advice. You can find their profile page here: https://www.plctalk.net/qanda/member.php?u=894870.
Unfortunately, resources for AS are limited, but I will contact him to express my gratitude for the information. In the meantime, I will research similar commands as I believe this is the optimal choice for my hardware. Any additional input from others would be greatly welcomed. Thank you!
I am considering developing a structured text program to implement FIFO array logic. While there are existing FIFO commands for ST, I have attached an image for reference. The machine's software currently only utilizes LD programs, so incorporating ST would be a new endeavor. Can anyone provide guidance on establishing communication between LD and ST? My goal is for the global variable "startArray" in my ladder program to trigger the execution of the ST program responsible for managing FIFO operations such as loading/unloading the array, calculating the sum of elements, and making decisions based on livePeriod vs. theoreticalPeriod (UserWorkDetected). How should I proceed with this integration, and what other factors should I consider? Keep in mind that there are additional LD programs running concurrently with this one. Thank you for any insights.
In the sidebar of B&R's Automation Help, I noticed a useful feature under Ladder/Contacts called a-]PN[-contact. This contact generates a one-shot pulse for 0-to-1 and 1-to-0 transitions of the input operation, perfect for applications like using encoder input as the operand (VarName). By using this-]PN[-contact instruction, you can receive 16 pulses per footplate cycle for efficient automation processes.
Thank you for your input, I will incorporate that as a simple change to increase the number of measurements per cycle from 8 to 16. At the moment, I am utilizing a circular FIFO array with 8 elements in my ST code (see attachment). I have encountered no issues with compilation, and all variables that overlap with my ladder programs are declared globally. Despite setting the StartArray global BOOL to high, none of the ST code seems to be executing. Can anyone identify what could be causing this issue? Some key variables to take note of include MainShaftSensor, which is the encoder sensor variable used to monitor pulses, and EffortLightOn, a variable indicating when user work is detected for display on the HMI.
Are you invoking the ST program directly? Or has it been enlisted in a running program list, assigned to a recurring task, or included in a scheduled interrupt task?
What assigns a value of 1 to the Boolean MainShaftSensor? There seems to be no purpose in duplicating the value from StatArray to STLogicStart, although it should not prevent the code from executing.
Within the LD code, it is possible to substitute the three contacts that supply the DIV with a sole contact that inspects the StartArray. This replacement can streamline the code and improve its efficiency.
Currently, cleanliness may not be optimal. The MainShaftSensor, an inductive sensor, detects metal from the attached encoder wheel. When metal is detected, MainShaftSensor is assigned a value of 1, also known as the encoder wheel pulse sensor. Modifications have been made to the ST to run the array only when StartArray is true, eliminating the unnecessary STLogicStart variable. The ST program has not been explicitly called anywhere, which could be a possible issue. It was assumed that setting the StartArray global variable to true would initiate the ST execution, but it may be necessary to do this in the LD using a FB. Further investigation is needed to establish communication for calling the ST from the LD program.
During testing, the program encountered an issue where the machine stopped and the PLC entered service mode when the StartArray condition was true. The problem was resolved by power cycling the device. Could this issue be caused by conflicting logic in the PLC?
During testing, a situation arose where the PLC entered service mode after the StartArray became true, causing a need for a device reset. This issue may have been caused by confusion within the PLC's logic. To resolve this, it was necessary to change the "WHILE ... DO" to "IF ... THEN."
The problem likely stemmed from a watchdog timeout occurring when the WHILE-DO-END_WHILE loop did not terminate on the initial scan cycle. The ST program CYCLIC failed to return in time, resulting in the PLC watchdog detecting an extended scan cycle and halting the system.
It is essential to understand the concept of a PLC scan cycle to prevent similar issues in the future. Remember, it is crucial to give precise instructions to the PLC to avoid unintended consequences.
I appreciate the assistance provided so far. Engaging with the community has been a valuable learning experience for this project. I encountered some challenges with variable calling, but I have managed to resolve them with ST now functioning correctly. Observing the program in action, I can see the FIFO accurately filling and updating as intended. The user work detection feature works effectively for lower RPM setpoints, however, higher RPMs result in a higher livePeriod calculation, making it harder to trigger the user work detection unless substantial work is performed.
I have identified a few potential causes for this issue:
1. The program currently runs on a 100ms cycle, which may be too slow for higher RPMs. Would reducing the scan time improve performance, especially considering the motor operates on a 1ms program?
2. I am currently using 8 measurements/rev based on the leading edge of the encoder wheel sensor. Would increasing this to 16 measurements impact the livePeriod calculation accuracy? Can the 100ms scan time handle processing and summing these additional measurements efficiently?
3. Implementing an interrupt for every high pulse on the encoder sensor instead of the current continuous scan method is another option to consider. While I am not familiar with interrupts, I am open to exploring this possibility for improved performance.
Any insights or advice on the next steps to take would be highly valuable. Your input is greatly appreciated. Thank you!
1. When dealing with a process that cycles every 2400ms (25RPM), it is important to consider the PLC scan cycle period of 100ms to avoid introducing aliasing in the sampling process.
2. Increasing the triggers per cycle affects the frequency of the liveRPM calculation without altering the results. However, it is essential to assess whether the PLC processor can handle this increase in triggers. With a trigger occurring every 150ms or less, a scan cycle period of 100ms may push the limits of edge detection instructions.
3. Utilizing an interrupt routine is recommended to reduce sample aliasing. By implementing the algorithm described in point 2.1, or by updating the FIFO within the interrupt routine and conducting additional calculations within the 100ms scan cycle, efficiency can be maximized.
1. The device can reach a maximum RPM setpoint of approximately 36-37 rpm. When monitoring the live setpoint RPM, it typically falls within a range of 35-40 rpm. Adjusting the task class to 50ms did not show a noticeable difference from 100ms. Lower RPMs were detected accurately, while higher RPMs were less sensitive. By setting a 20ms scan time, the device now operates effectively at both lower and higher RPMs, particularly for shorter stride lengths. Actuators can modify the step "stride length" from 10 to 24 inches based on user height. While the device functioned well at lower stride lengths (10-14 inches), larger strides (17 inches and above) resulted in spikes of user activity without actual work being performed. Apart from adjusting the task class, no changes were made to the program. I appreciate utilizing this method involving the period, although I am uncertain about the next steps.
2. To clarify, instead of having 8 triggers per revolution, there are now 16 triggers per revolution. Therefore, the array must accommodate 16 elements. The confusion stems from pulsePeriod representing the time between two rising edges of the sensor, equivalent to 8 measurements per revolution. If transitioning from 8 to 16 triggers, both the ON and OFF times would need to be utilized to store the FIFO in order to hold 16 elements. I hope I articulated that clearly enough. Could you provide further explanation on this approach?
3. I assume interrupts take precedence during scanning. If there are no conflicting programs, I am willing to give it a try. How should I modify my ST code for this? Thank you once again.
1. Is a longer stride length associated with a slower base RPM when MPH is constant? If so, it should be easier for the PLC to handle longer strides due to longer time between encoder transitions. The observation of longer stride lengths generating spikes is puzzling. How exactly are you determining the pulsePeriod? What clock are you using to measure the time between encoder edges? What is the resolution of this clock, in terms of bits and time representation per tick? Does the clock "roll over" when reaching its maximum value before incrementing to 0 on the next tick?
2. Currently, for eight triggers per cycle, pulsePeriod is calculated between each pair of successive rising edges. For sixteen triggers, pulsePeriod needs to be calculated between each pair of rising/falling and falling/rising edges.
2.1. In the existing code, at each rising edge, the difference between the current and previous rising edge's absolute clock times is calculated as the pulsePeriod and stored in a FIFO queue. The values shift with each edge due to the circular array. The sum of these values gives the total period for one cycle. The current absolute clock time becomes the previous time for the next pulsePeriod calculation at the next edge.
In place of individual calculations for each encoder pulsePeriod, storing absolute clock values at each edge in the FIFO could simplify the process and code.
3. To modify your current ST code for integration with interrupts, make it the code called by the interrupt. Save two absolute clock times outside the FIFO array: the latest interrupt time and the time of the 8th previous interrupt, which was replaced. Update the circular pointer in the FIFO accordingly. Specific adjustments will be needed based on your PLC brand and model. Edge detection in software will no longer be necessary as the interrupt handler will handle it.
drbitboy mentioned a FIFO array with eight elements, and rough modeling curves have been provided for reference. It is recommended to examine the actual measured curves for more accurate data.
After reading your previous discussion on accumulated effort, I have been contemplating the various types of effort that could be measured. In my perspective, there are two distinct categories of effort. The first involves the individual on the treadmill attempting to surpass the motor's pace, leading to a decrease in motor current compared to the baseline. The other category pertains to what can be described as futile effort, where the individual is essentially working against the motor in an attempt to slow it down, resulting in an increase in motor current compared to the baseline.
Differentiating between these two types of effort is essential if your goal is to enhance the person's efficiency on the treadmill. However, if the objective is solely to quantify the individual's energy expenditure, the distinction between aiding and opposing the motor becomes less significant. In conclusion, understanding the nuances of effort in relation to the treadmill can greatly impact the effectiveness of your project.
Indeed, Steve, you are correct. When users exert effort to assist the motor, there is a decrease in current. One common exercise that clinicians perform with patients using the device is to have them oppose the device's movement and keep the footplates stationary. This results in the maximum current being drawn, and the current trendline appearing to "flatline" as it is held in place. This distinction can be detected through the current readings or by monitoring the encoder sensors; if the sensor remains static in the on/off position, it indicates that the user is maintaining a steady position. I will develop a method for detecting this differentiation, as well as incorporating feedback from earlier discussions. Thank you for sharing your insights.
The motor current of a treadmill is likely correlated with the user's weight. To increase accuracy, it is recommended to create baseline current profiles for various weight categories. You can mimic an 80 kg person by placing 40 kg on each footplate and tracking the current over time or shaft angle. Any deviation from this baseline profile when a live 80 kg person is on the treadmill indicates exertion. This method allows for a more precise and personalized tracking of workout intensity.
In a forum discussion, AFM mentioned working on a project involving a robotic gait trainer designed to detect when a user is actively engaging with the system, similar to an elliptical machine. Do you collect data on how the device interacts with the patient, such as changes in frequency based on the user's efforts? What musculoskeletal disorders does your data cover? Can you explain the consistency of the patient's impact on the device, especially in cases where one leg is impaired compared to both legs being fully functional? In a previous post, AFM illustrated the challenge of extracting valuable information from input data by showcasing pulse duration curves and the potential chaos resulting from uneven patient interaction with the device.
Hello everyone, apologies for the delay in responding. This project has been paused to allow the UI team to make some developments with the alpha software, which requires "scans" to establish a baseline. Steve Bailey suggested that motor current is likely proportional to the weight of the person using the treadmill. To improve accuracy, it may be beneficial to create baseline current profiles for different weight ranges of treadmill users. For instance, simulating an 80 kg person by placing 40 kg on each footplate can help chart current changes. Any deviations from this profile with an actual 80 kg person indicates effort exerted.
It was noted that the sensitivity of the current output depends on the setting of the jumper on the 4-20 mA current transducer. After a thorough data collection phase, it was found that the current value gradually decays over time, making it difficult to establish a reliable reference or profile. Therefore, an alternative approach of rescanning is being explored to address this issue.
MaxK raised questions regarding the device's interaction with the patient and the coverage of musculoskeletal disorders in the data. Additionally, concerns were raised about the consistency of a patient's influence on the device, especially when dealing with uneven impacts such as leg injuries. The importance of understanding these interactions was highlighted through the demonstration of the complexities in interpreting input data.
When observing the raw sensor output data during machine use, minor changes in current are noticeable, especially with unilateral or bilateral work. The impact of slight movements, such as kicks against the footplates, can result in spikes in current. Similarly, engaging in low levels of consistent work, such as "walking with the device," can cause a slight rise in the current wave. However, distinguishing between work and non-work periods is challenging due to the oscillation and overlap of values.
In addition to the earlier discussion, I am currently working on implementing a system to detect the position of the footplates. At present, there is no fixed reference point for the controls to determine when the footplates are aligned or at the ends of a step. The existing setup includes an inductive sensor paired with a metal encoder wheel containing 8 equally sized segments. The starting position of the footplates is unknown, so we can only track one revolution (equivalent to 2 steps). To address this, I am considering several options:
1. Upgrading to an incremental encoder to utilize its z-signal, which may incur additional costs.
2. Installing a second encoder wheel and inductive sensor on the opposite footplate linkage.
3. Adding a second inductive sensor to the same encoder wheel and incorporating a second set of segments.
I am currently leaning towards the third option as it would require minimal changes to the existing control logic. The plan involves maintaining the outer ring with 8 segments and introducing an inner ring with a single open segment to indicate when the footplates are aligned. By using the pulse counter from the first inductive sensor as a reference point, I can set the following parameters:
- 2 pulses: front extreme of step
- 4 pulses: footplates are aligned (1 step completed)
- 6 pulses: back extreme of step
- 8 pulses: footplates are aligned (1 revolution = 2 steps completed)
If you have any simpler alternatives or suggestions, please feel free to share. Thank you for your input!